Добавлен: 21.10.2018
Просмотров: 1042
Скачиваний: 6
Обязательные разделы: Постановка задачи, Выбор СУБД (в сравнении), Описание структуры таблиц, Описание поддержки целостности данных (связи), Скрипт на создание стуктуры БД (на SQL), запросы которые приведены в задании
Вариант 6. Разработка базы данных для работников регистратуры поликлиники
В БД должны храниться сведения о больных (ФИО, адрес, диагноз, дата заболевания, номер страхового полиса, название страховой компании), сведения о врачах (ФИО, номер кабинета, номер участка, дни и часы приема), описание болезней (название, симптомы, лекарство).
Работникам регистратуры могут потребоваться следующие сведения:
-
адрес, дата заболевания, диагноз данного больного;
-
ФИО лечащего врача данного больного;
-
номер кабинета, дни и часы приема данного врача;
-
список больных, находящихся на лечении у данного врача.
Пользователь может вносить следующие изменения: осуществлять ввод данных о новом больном, удалять из БД информацию об уволенных врачах, редактировать данные о больном.
1. ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ
1.1 Стадии и этапы разработки баз данных
Процесс разработки БД – это итеративный процесс, в ходе которого обычно приходится многократно возвращаться к предыдущим этапам выполнения работы, вносить необходимые изменения и затем заново повторять последующие этапы до достижения необходимого результата.
Процесс разработки базы данных можно разбить на две стадии:
1. Проектирование базы данных.
2. Программная реализация базы данных.
Стадия проектирования БД включает следующие основные этапы:
1. Обследование предметной области.
2. Инфологическое проектирование (разработка инфологической модели предметной области).
3. Даталогическое проектирование.
В БД хранится информация об определенной предметной области.
Предметной областью называется часть реального мира, представляющая интерес для данного исследования (использования) и отражаемая в базе данных.
Для формирования представления о данных, их составе и использовании в конкретных условиях служат информационные модели (ИМ). При решении конкретных задач реальная действительность воспроизводится с существенными ограничениями, зависящими от области деятельности, поставленных целей.
Значит, для создания БД надо сначала проанализировать предметную область и создать её информационную модель.
Основой для анализа предметной области служат документы, которые ее отражают, и информация, которую можно получить от специалистов этой предметной области в процессе общения с ними.
Для анализа берутся те документы, которые имеют отношение к решаемой задаче. Изучение документов позволяет выявить объекты и их свойства, информацию о которых необходимо хранить в БД.
Из общения со специалистами необходимо извлечь сведения об особенностях предметной области, которые позволяют установить ограничения целостности, зависимости и связи между объектами (субъектами) предметной области.
Модель предметной области может быть описана любым удобным для разработчика способом (словесное описание, набор формул, диаграмма потоков данных и т.п.).
При проектировании баз данных используется диаграмма «сущность–связь» (ER–диаграммы (entity-relation diagram)).
На следующем этапе – этапе даталогического проектирования – ER-диаграмма формальным способом преобразуется в схему реляционной базы данных (БД). На основании схемы БД и описания сущностей предметной области составляются таблицы (отношения) базы данных. Потом выполняется нормализация отношений. Это необходимо сделать для того, чтобы исключить нарушения логической целостности данных и повысить, таким образом, надёжность и достоверность данных.
В результате всех этих операций создаётся схема БД – основной документ для базы данных.
Программная реализация базы данных
На этом этапе полученная схема базы данных описывается на языке DDL (Data definition language) – языке определения данных, который поддерживается выбранной СУБД.
Стадия программной реализации БД содержит работы:
1. Создание таблиц.
2. Создание межтабличных связей (для поддержки целостности данных).
3. Разработку процедур обработки данных (написание текста создания вспомогательных объектов базы данных (представления, хранимые процедуры, триггеры и т.д.)).
4. Отладку БД.
5. Тестирование БД (выполнение контрольных примеров).
6. Разработка эксплуатационной документации БД.
Если пользователей базы данных можно разделить на группы по характеру решаемых задач, то для каждой группы создаётся свой набор прав доступа к объектам БД.
1.2. Последовательность проектирования базы данных
Процесс проектирования базы данных включает в себя следующие шаги:
1. Определение задач, стоящих перед базой данных.
2. Сбор и анализ документов, относящихся к исследуемой предметной области.
3. Описание особенностей предметной области, которые позволяют установить зависимости и связи между объектами предметной области.
4. Создание модели предметной области.
5. Определение групп пользователей и перечня задач, стоящих перед каждой группой.
6. Выбор СУБД (системы управления базой данных).
7. Создание логической схемы БД.
8. Создание схем таблиц, определение типов данных атрибутов и ограничений целостности.
9. Нормализация отношений (до третьей или четвёртой нормальной формы).
10. Определение прав доступа пользователей к объектам БД.
11. Написание текста создания основных объектов базы данных на языке SQL в синтаксисе выбранной СУБД (пользователи, таблицы и др.).
12. Написание текста создания вспомогательных объектов базы данных (представления, хранимые процедуры, триггеры, роли и т.д.).
Эти шаги можно объединить в 4 этапа:
1. Инфологическое проектирование (1-5).
2. Выбор системы управления базой данных (СУБД) и других инструментальных программных средств (6).
3. Логическое проектирование БД (7-10).
4. Программная реализация базы данных (11-12).
На сегодняшний день не существует формальных способов моделирования реальности, но инфологический подход закладывает основы методологии проектирования базы данных как модели предметной области.
1.3 Инфологическое проектирование
Цель инфологического проектирования - построение независимой от СУБД информационной структуры путем объединения информационных требований пользователей. Результатом этого этапа является представление информационных требований в виде диаграмм «сущность-связь».
Основными задачами этапа инфологического проектирования являются определение предметной области системы и формирование взгляда на неё с позиций сообщества будущих пользователей БД, т.е. информационно-логической модели предметной области.
Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).
Сущность – это реальный объект предметной области, о котором в системе будут накапливаться данные.
Сущности представляют собой объекты, которые пользователи считают важными в моделируемой предметной области. Примерами сущностей могут быть люди, автомобили, дома, книги, компании, штатное расписание.
На диаграммах «сущность – связь» сущности представляют в виде прямоугольника, содержащего внутри название.
Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Иваново и т.д.
Каждая сущность обладает определенными свойствами. Например, у человека есть имя, дата рождения, вес, рост.
Атрибут – поименованная характеристика (свойство) сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.).
Атрибуты используются для определения того, какая информация должна быть собрана о сущности.
Атрибуты на диаграмме «сущность-связь» изображаются в виде овалов, прикрепленных к соответствующей сущности (рис. 1).
Рисунок. 1. Представление сущности и ее атрибутов
Важно понимать, что сущности нужно в концептуальном плане отделять от атрибутов, которые их описывают, т.к. значения атрибутов могут меняться, в то время как описываемый ими объект остается прежним. Например, у человека может измениться рост, вес, семейное положение, но это будет тот же самый человек.
Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность. Например, для автомобильного завода цвет – это только атрибут продукта производства, а для лакокрасочной фабрики цвет – тип сущности.
Ключ – это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности.
Например, для сущности ЧЕЛОВЕК ключом является атрибут Номер страхового свидетельства или набор атрибутов имя, дата рождения. На диаграммах сущность – связь ключ подчеркивают одинарной сплошной линией (рис. 1).
Часто в качестве ключей применяют так называемые суррогатные ключи. Это искусственно сформированные внутренние номера без смысла вне базы данных, которые однозначно определяют элемент сущности. Использование суррогатных ключей предпочтительнее по сравнению с использованием составных ключей, так как уменьшается вероятность нарушения целостности данных из-за ошибок в одном из атрибутов.
Две и более сущности могут быть связаны между собой отношением.
Связь это ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.
Связь устанавливается между экземплярами сущностей, а не их типами. Например, для сущностей КЛИЕНТ и ЗАКАЗ связь устанавливается между конкретным клиентом и его заказами. Для связывания экземпляров сущностей используются их уникальные идентификаторы экземпляров сущности (ключи).
Графически связи между двумя сущностями представляется в виде соединяющего их отрезка, дополненного ромбом.
Существуют две важные характеристики связей: показатель кардинальности между сущностями и класс принадлежности сущностей.
Показатель кардинальности – это число экземпляров одной сущности, связанных с одним экземпляром другой сущности.
В зависимости от показателя кардинальности различают следующие типы бинарных связей:
- один – к – одному (1:1) (one-to-one relationship);
- один – ко – многим (1:М) (one-to-many relationship);
- многие – ко – многим (М:М) (many – to – many relationship).
Класс принадлежности – признак, определяющий обязательность участие экземпляров сущности в некоторой связи.
Класс принадлежности называется обязательным, если все экземпляры данной сущности должны участвовать в некоторой связи.
В таблице 1 приведены обозначения связей с различными характеристиками.
Таблица 1
|
Класс принадлежности |
Показатель кардинальности |
|
|
1 |
n |
|
|
Необязательный |
возможно только один |
возможно несколько |
|
Обязательный |
обязательно только один |
по крайней мере только один |
Примеры связей с различными показателями кардинальности и классами принадлежности приведены на рис. 2 .
Рисунок 2. Примеры связей
Каждый экземпляр сущности ЖЕНАТЫЙ МУЖЧИНА должен быть обязательно связан с одним экземпляром сущности ЗАМУЖНЯЯ ЖЕНЩИНА, т.е. класс принадлежности с обеих сторон обязательный, а показатель кардинальности – один к одному (1:1). Предполагается, что один инспектор может контролировать несколько рабочих, а каждого рабочего контролирует только один инспектор. Такая связь будет иметь показатель кардинальности один-ко-многим (1:М). Класс принадлежности с обеих сторон обязательный, т.к. все ИНСПЕКТОРА занимаются контролем, а все РАБОЧИЕ контролируются. В случае сущностей АВТОМОБИЛЬ и АЗС показатель кардинальности много-ко-многим (М:М). Каждый Автомобиль может заправиться на разных АЗС, а на одной АЗС могут заправляться разные АВТОМОБИЛИ. Класс принадлежности со стороны сущности АЗС необязательный, т.к. АЗС может быть закрыта на ремонт, следовательно, на этой АЗС не может заправиться ни один автомобиль, т.е. с этой АЗС не будет связан ни один экземпляр сущности АВТОМОБИЛЬ.
1.4. Примеры построения моделей «сущность – связь»
Рассмотрим пример модели данных банка. Сущностями для банка являются СБЕРЕГАТЕЛЬНЫЙ СЧЕТ, ТЕКУЩИЙ СЧЕТ, КЛИЕНТ. Клиент может иметь как текущий, так и сберегательный счет. В общем случае клиент может иметь несколько счетов, а каждым счетом могут пользоваться несколько клиентов. Таким образом, отношения ИМЕЕТ СБЕРЕГАТЕЛЬНЫЙ СЧЕТ и ИМЕЕТ ТЕКУЩИЙ СЧЕТ являются отношениями вида много-ко-многим, причем если существует счет, то он должен принадлежать хотя бы одному клиенту (класс принадлежности со стороны клиента – обязательный, со стороны счета - необязательный). Клиентом банка может быть как физическое, так и юридическое лицо. Добавив к каждой сущности атрибуты, получим модель, представленную на рис. 3.
Рисунок 3. Модель «сущность – связь» структуры данных банка
Модель данных «сущность – связь» может строиться как на основе опроса руководителей и специалистов отделов предприятия, так и на основе существующих отчетов. При разработке БД на основе документации, принятой на предприятии, сущности, атрибуты и связи между ними будут отражать существующую систему учета. Если необходимо учитывать и какие-либо другие данные, не отраженные в документах, то после разработки модели ее нужно будет корректировать и дополнять с учетом пожеланий заказчиков.
Рассмотрим пример построения модели «сущность – связь» торговой фирмы на основе накладной. Пример накладной приведен в таблице 2.
Таблица 2
|
Накладная № 33 Получатель Фирма АВС, г. Владимир, тел. 999999 Код получателя 999 Поставщик Фирма ХХХ Дата 01.01.2018 |
||||
|
Наименование |
Номенклатурный номер |
Количество |
Цена |
Сумма |
|
Транзистор КТ601АМ |
7125692 |
100 |
2.00 |
200.00 |
|
Микросхема 133ИЕ8 |
7504870 |
20 |
5.00 |
100.00 |
|
Налог |
60.00 |
|||
|
ИТОГО |
360.00 |
|||