Студопедия  
Главная страница | Контакты | Случайная страница

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Поля записи

Читайте также:
  1. II раздел. Задания этого раздела выполняются студентами самостоятельно письменно или устно (в записи на электронном носителе).
  2. II раздел. Задания этого раздела выполняются студентами самостоятельно письменно или устно (в записи на электронном носителе).
  3. Алгоритм и его способы записи(язык програмирования,псевдокод,блок-схема).
  4. Алгоритм тестирования НГМД методом записи-чтения со сравнением.
  5. Алгоритм. Свойства алгоритма. Способы записи алгоритма
  6. Анализ, компиляция и прогон программы для создания memory mapped файла и записи его содержимого
  7. Виды записи краткого условия задач
  8. Дано натуральное число N. Получить новое число путём удаления всех 1 из числовой записи числа.
  9. Для регистрации хозяйственных операций на счетах бухгалтерского учета используется способ двойной записи.
  10. ЕЖЕДНЕВНЫЕ ЗАПИСИ СТУДЕНТА

1. Б

2. А

3. Г

4. А

5. В

6. А

7. Б

8. А

9. В

10. В

11. В

12. Б

13. Б

14. А

15. А

16. В

17. А

 

Тема 1.9 «Особенности аптечного изготовления лекарств. Рациональная организация и аттестация рабочих мест. Организация внутриаптечного контроля качества ЛС.»

1. Б

2. А

3. А

4. Б

5. А

6. А

7. В

8. В

9. В

10. Б

11. А

12. Б

13. В

14. Е

15. Б

16. В

17. В

18. А

19. Г

20. Д

21. Г

22. Г

23. В

24. Г

25. Г

 

Тема 1.10 «Основные принципы хранения лекарств в аптечных организациях»

1. А

2. Б

3. Б

4. В

5. А

6. Г

7. А

8. Г

9. Г

10. А

11. Б

12. В

13. Б

14. А

15. В

16. А

17. В

18. Г

19. Г

20. А

 

Тема 1.11 «Организация лекарственного обеспечения стационарных больных. Фармакоэкономический анализ»

1. Г

2. А

3. В

4. А

5. В

6. А

7. А

8. А

9. Б

10. В

11. А

12. А

13. В

14. А

15. А

16. А

17. А

18. В

19. Г

20. А

21. Б

22. А

23. Б

24. Б

 

Тема 1.12 «Организация деятельности оптовых фармацевтических предприятий»

1. Г

2. А

3. А

4. А

5. А

6. Б

7. В

8. В

9. А

10. А

11. В

12. Б

13. В

14. А

15. Б

16. А

17. В

18. Г

19. Б

20. А

21. Б

ЛЕКЦИЯ 13

Организация информационного фонда на ЭВМ с использованием баз данных

Организация информационного фонда на ЭВМ с использованием баз данных (БД) применяется во многих современных САПР ТП.

База данных - совокупность структурированных данных, используемых многими прикладными программами и хранящихся с минимальной избыточностью.

Система управления базой данных (СУБД) - программный комплекс, обеспечивающий создание структуры, ввод, модификацию, удаление и поиск данных.

Иногда используется понятие банка данных (БнД), под которым понимается совокупность БД и СУБД.

Самой распространенной в настоящее время является СУБД Microsoft Access 2002, которая является одним из продуктов пакета Microsoft Office ХР.

Основные требования, предъявляемые к базам данных

К базам данных предъявляется ряд требований, среди которых можно выделить следующие основные требования:

1. Минимальная избыточность. Каждый элемент данных вводится в БД один раз и хранится в единственном экземпляре. При вводе данных СУБД выполняет проверку на дублирование. Этим достигается экономия внешней памяти и надежность информации.

2. Независимость. Модификация данных и изменения, вносимые в их структуру в связи с появлением новых пользователей и новых запросов, не должны отражаться на программах пользователей.

3. Целостность данных:

- логическая (СУБД должна защищать БД от некорректных действий пользователей путем восстановления состояния БД на момент, предшествующий ошибочной операции);

- физическая (защита носителей информации - дисков - от сбоев путем дублирования, например, двумя параллельно работающими зеркальными дисками).

4. Секретность. Пользователи должны работать только с теми данными (фрагментами данных), к которым им разрешен доступ.

Основные понятия и основы проектирования баз данных

Начнем с определения понятия «данные». Итак, данные - это информация, представленная в определенной форме, пригодной для хранения и обработки на ЭВМ. Можно дать и другое определение: данные - это представленные в цифровом виде сведения о некоторых объектах окружающего нас мира (об объектах интересующей нас предметной области).

При создании любой БД разрабатывается модель данных. При этом интересующая пользователей БД информация существует в двух представлениях:

1. Логическое представление данных.

2. Физическое представление данных на носителе информации (диске).

Логическое представление отражает структуру данных. Модель не содержит конкретных значений. Она только описывает их структуру. В дальнейшем структура остается неизменной, а данные могут меняться при вводе и редактировании информации в БД.

Для определения модели используются следующие понятия:

• объект;

• атрибут;

• экземпляр;

• ключ.

ЛЕКЦИЯ 13 Стр. 2 из 5

В дальнейшем мы укажем на соответствующие этим понятиям понятия, используемые при описании физического представления данных и понятия, принятые в СУБД Microsoft Access.

Объект представляет собой то, о чем накапливается информация в БД, например «сверло», «зенкер», «резец» и т.д.

Атрибуты - это интересующие пользователя характеристики объекта. Например, для объекта «сверло» - это «обозначение», «диаметр», «длина общая» и т.д.

Экземпляр объекта - совокупность значений атрибутов, описывающих конкретную его реализацию. В нашем случае это строка таблицы.

Ключ - это атрибут, значение которого однозначно определяет экземпляр. Так в БД по сверлам (см. ниже) ключом может служить атрибут «обозначение», т.к. значение этого атрибута не дублируется ни в одной строке (экземпляре). Другие атрибуты не могут быть ключом, потому что могут принимать одинаковые значения для разных экземпляров. Например, вполне возможны два сверла с одинаковой длиной, хотя и разного исполнения.

При описании физического представления данных, а также в терминологии СУБД Microsoft Access понятию «атрибут» соответствует понятие «поле» (столбец таблицы). Понятию «экземпляр» соответствует понятие «запись» (строка таблицы). Объекту соответствует фрагмент файла данных или файл данных целиком.

База данных, состоящая из набора связанных между собой двумерных (плоских) таблиц, называется реляционной базой данных. Данные в этих таблицах организованы таким образом, чтобы обеспечить объединение разнородной информации, исключить ее дублирование, а также предоставить оперативный доступ к имеющимся сведениям и эффективное сопровождение базы данных в целом.

Реляционные СУБД используют реляционную модель данных, предложенную в 1970 году Э.Ф-Коддом. Если говорить упрощенно, то Кодд показал, что набор двумерных таблиц при соблюдении определенных ограничений может быть использован для хранения данных об объектах реального мира и моделирования связей между ними. В терминологии Кодда такие таблицы называются отношениями (англ.relation), вот почему подобная база данных называется реляционной.

В реляционной базе данных, в частности, реализованной в СУБД Microsoft Access, для однозначного распознавания экземпляра объекта подобно приведенному выше понятию «ключ» вводится уникальный идентификатор - первичный ключ. Первичный ключ - это уникальная характеристика для каждой записи в пределах таблицы. Первичный ключ таблицы помимо однозначной идентификации записей позволяет реализовать и связи между таблицами. Благодаря связям информация из одной таблицы становится доступной для другой. Связи устанавливаются за счет того, что в разных таблицах присутствуют поля с одинаковыми значениями.

Покажем на примере преимущества реляционных моделей данных перед моделями данных, построенными на основе сплошных таблиц.

Пример. Разработка фрагмента модели данных «Сотрудники - проекты». Пусть речь идет о технологической службе предприятия, сотрудники которой, занимаясь технологической подготовкой производства, естественным образом участвуют в разработке проектов некоторых изделий. Исходные данные по сотрудникам представлены в так называемой сплошной таблице -см. табл. 13.1.Таблица 13.1Исходная сплошная таблица «Сотрудники - проекты»

Номер сотрудника   Номер проекта   Номер задания   Фамилия   Должность   Оклад   Отдел  
  АВ-115   1.1   Петров   Инженер-технолог      
  KN-20   1.3   Петров Инженер- технолог      
  ZТ-14   5.2   Васильев   Инженер-технолог      
  ZТ-14   5.4   Куликов   Техник      
  АК-177   1.2   Зорин   Начальник отдела      
  ВС-18   3.6   Зорин Начальник отдела      

В данной таблице имеются следующие недостатки в представлении данных:

ЛЕКЦИЯ 13 Стр. 3 из 5

1. Дублируется информация о сотрудниках, т.к. сотрудник может участвовать в нескольких проектах.

2. В таблицу нельзя вписать тех сотрудников, которые не заняты в проектах именно сейчас, а также сотрудников, которые вообще не работают над проектами, иначе таблица не будет сплошной.

3. Если сотрудник увольняется, запись о нем удаляется из таблицы, а вместе с ней - и проект, хотя работа над ним должна продолжаться.

Данный пример является классическим, поскольку отмеченные выше проблемы характерны для всех сплошных файлов. Снять указанные ограничения и позволяют реляционные базы данных. В них при проектировании таблиц и определении связей следуют формализованной процедуре, которая называется нормализацией и опирается на аппарат теории множеств и реляционной алгебры. Нормализация - это пошаговый процесс замены одной таблицы другими, имеющими более простую структуру. На каждом шаге (этапе) нормализации таблицы приводятся к некоторому определенному виду, который называется нормальной формой.

Чтобы устранить указанные выше недостатки, разобьем исходную таблицу на две: «Проекты» и «Сотрудники» - табл. 13.2 и 13.3.

Таблица 13.2 Проекты

Номер сотрудника   Номер проекта Номер задания  
  АВ-115   1.1  
  лт-20   1.3  
  ZТ-14 5.2  
  ZТ-14 5.4  
  2122 АК-177  
      ВС-18   3.6      
Сотрудники  
Номер сотрудника   Фамилия   Должность   Оклад   Отдел   Телефон    
  Петров   Инженер-технолог       6-15    
  Васильев   Инженер-технолог       6-19  
  Куликов   Техник       5-41  
  Зорин   Начальник отдела       6-88    
                   

 

Продолжим анализ и посмотрим на таблицу «Сотрудники». Несложно заметить следующие особенности:

1. Дублируется информация о телефонах для сотрудников одного отдела.

2. Если изменяется телефон отдела, необходимо изменять его у всех сотрудников отдела. Аналогичная ситуация будет наблюдаться при изменении размера окладов.

3. Нельзя включить данные о новом отделе, пока не будут набраны его сотрудники.

4. При увольнении все сотрудников не сохраняются данные о самом отделе.

Поэтому, следуя правилам нормализации, необходимо выполнить декомпозицию таблицы «Сотрудники» и разбить ее на три таблицы: «Сотрудники», «Должности», «Отделы» - табл.13.4, 13.5,13.6.

 

ЛЕКЦИЯ 13 Стр.4 из 5

Таблица 13.4 Сотрудники (окончательная таблица)

Номер сотрудника   Фамилия   Должность   Отдел  
  Петров   Инженер-технолог    
  Васильев   Инженер-технолог    
  Куликов   Техник    
  Зорин   Начальник отдела    

 

Таблица 13.5Должности

Должность   Оклад  
Инженер-технолог    
Техник    
Начальник отдела    

 

Таблица 13.6Отделы

Отдел   Телефон  
  6-15  
  5-46  
  6-88  

Т.е окончательно сформированы четыре связанные между собой таблицы: «Проекты», «Сотрудники», «Должности» и «Отделы».

Покажем теперь логику представления фрагмента данных в БД «Режущие инструменты», а более подробно в ее разделе «Сверла». Информация о сверлах берется из справочника - см. табл. 13.7.

Табл.13.7Справочная информация о сверлах

Обозначение   Диаметр, мм   Длина общая, мм   Длина режущей части, мм   Код хвостовика   Материал   ГОСТ  
…… …   ...   …   …   …   …  
  19,00       Морзе 2   Р6М5    
  19,25       Морзе 2   Р6М5    
...                      

Общая структура данных показана на рис. 13.1.

Объекты

Диаметр  
Длина реж. части     Хвостовик  

 

Рис. 13.1. Общая структура данных БД «Режущие инструменты»

ЛЕКЦИЯ 13 Стр. 5 из 5

После определения типа данных (здесь применяется два типа данных: «текстовый» - обозначен ниже буквами «С» и «числовой» - буквами «N») и длины полей получается логическая модель данных - рис. 13.2.

Поля записи

DB D L LR KX KM GOST

CCC   NN.NN   NNN   NNN   CCCCCCC   CCCCCC   CCCCCC  

 

 

065 19.00 238 135 Морзе 2 Р6М5 10903←Запись i

066 19.25 238 140 Морзе 2 Р6М5 10903←запись i+1

Рис. 13.2. Логическая модель данных в БД «Режущие инструменты» в разделе «Сверла»

Ввиду того, что львиная доля работы по проектированию технологических процессов приходится на работу с данными и при этом перерабатывается очень большое количество информации, ряд САПР ТП построено на основе имеющихся СУБД. Это значительно облегчает создание прикладного программного обеспечения САПР. Так, например, САПР ТП «Техно/Про» построена на базе уже упоминавшейся СУБД Microsoft Access. Информация об этом мощном приложении изложена в специальной литературе и требует отдельного изучения, что не входит в рамки данной дисциплины. Отметим только, что физическое представление данных на диске в данной СУБД организуется в виде одного общего файла, файла базы данных, который имеет расширение .mdb.




Дата добавления: 2015-01-05; просмотров: 23 | Поможем написать вашу работу | Нарушение авторских прав

<== предыдущая лекция | следующая лекция ==>
Тема 1.8 «Организация безрецептурного отпуска аптечных товаров. Принципы мерчандайзинга».| МИНИСТЕРСТВО КУЛЬТУРЫ РОССИЙСКОЙ ФЕДЕРАЦИИ

lektsii.net - Лекции.Нет - 2014-2024 год. (0.014 сек.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав