Модели и типы баз данных
Понятие и закономерности формирования баз данных, их содержание и внутренние элементы. Сущность и значение информационного объекта. Нормализация отношений. Сведенья о моделях данных и методика их проектирования. Конструирование базы данных и ее анализ.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 07.06.2012 |
| Размер файла | 346,6 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
К У Р С О В ОЙ ПРОЕКТ
«Модели и типы баз данных»
ВВЕДЕНИЕ
Современная жизнь немыслима без эффективного управления. Важной категорией являются системы обработки информации, от которых во многом зависит эффективность работы любого предприятия ли учреждения. Такая система должна: обеспечивать получение общих и / или детализированных отчетов по итогам работы; позволять легко определять тенденции изменения важнейших показателей; обеспечивать получение информации, критической по времени, без существенных задержек; выполнять точный и полный анализ данных. Современные СУБД в основном являются приложениями Windows, так как данная среда позволяет более полно использовать возможности персональной ЭВМ, нежели среда DOS. Снижение стоимости высокопроизводительных ПК обусловил не только широкий переход к среде Windows, где разработчик программного обеспечения может в меньше степени заботиться о распределении ресурсов, но также сделал программное обеспечение ПК в целом и СУБД в частности менее критичными к аппаратным ресурсам ЭВМ.
Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер». Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров.
1. Теоретическая часть
1.1 Базы данных
база данные информационный модель
Цель любой информационной системы - обработка данных об объектах реального мира. В широком смысле слова база данных - это совокупность сведений о конкретных объектах реального мира в какой-либо предметной области. Под предметной областью принято понимать часть реального мира, подлежащего изучению для организации управления и, в конечном счете, автоматизации, например предприятие, вуз и т.д. Создавая базу данных, пользователь стремится упорядочить информацию по различным признакам и быстро извлекать выборку с произвольным сочетанием признаков. Сделать это возможно, только если данные структурированы. Структурирование - это введение соглашений о способах представления данных. Неструктурированными называют данные, записанные, например, в текстовом файле. Пользователями базы данных могут быть различные прикладные программы, программные комплексы, а также специалисты предметной области, выступающие в роли потребителей или источников данных, называемые конечными пользователями. В современной технологии баз данных предполагается, что создание базы данных, ее поддержка и обеспечение доступа пользователей к ней осуществляются централизованно с помощью специального программного инструментария - системы управления базами данных. База данных (БД) - это поименованная совокупность структурированных данных, относящихся к определенной предметной области. Система управления базами данных (СУБД) - это комплекс программных и языковых средств, необходимых для создания баз данных, поддержания их в актуальном состоянии и организации поиска в них необходимой информации.
Централизованный характер управления данными в базе данных предполагает необходимость существования некоторого лица (группы лиц), на которое возлагаются функции администрирования данными, хранимыми в базе.
Классификация баз данных
По технологии обработки данных базы данных подразделяются на централизованные и распределенные. Централизованная база данных хранится в памяти одной вычислительной системы. Если эта вычислительная система является компонентом сети ЭВМ, возможен распределенный доступ к такой базе. Такой способ использования баз данных часто применяют в локальных сетях ПК. Распределенная база данных состоит из нескольких, возможно пересекающихся или даже дублирующих друг друга частей, хранимых в различных ЭВМ вычислительной сети. Работа с такой базой осуществляется с помощью системы управления распределенной базой данных (СУРБД).
По способу доступа к данным базы данных разделяются на базы данных с локальным доступом и базы данных с удаленным (сетевым) доступом.
Системы централизованных баз данных с сетевым доступом предполагают различные архитектуры подобных систем:
* файл-сервер;
* клиент-сервер.
Файл-сервер. Архитектура систем БД с сетевым доступом предполагает выделение одной из машин сети в качестве центральной (сервер, файлов). На такой машине хранится совместно используемая централизованная БД. Все другие машины сети выполняют функции рабочих станций, с помощью которых поддерживается доступ пользовательской системы к централизованной базе данных. Файлы базы данных в соответствии с пользовательскими запросами передаются на рабочие станции, где в основном и производится обработка. При большой интенсивности доступа к одним и тем же данным производительность информационной системы падает. Пользователи могут создавать также на рабочих станциях локальные БД, которые используются ими монопольно.
Клиент-сервер. В этой концепции подразумевается, что помимо хранения централизованной базы данных центральная машина (сервер базы данных) должна обеспечивать выполнение основного объема обработки данных. Запрос на данные, выдаваемый клиентом (рабочей станцией), порождает поиск и извлечение данных на сервере. Извлеченные данные (но не файлы) транспортируются по сети от сервера к клиенту. Спецификой архитектуры клиент-сервер является использование языка запросов SOL.
Структурные элементы базы данных
Понятие базы данных тесно связано с такими понятиями структурных элементов, как поле, запись, файл (таблица). Поле - элементарная единица логической организации данных, которая соответствует неделимой единице информации - реквизиту. Для описания поля используются следующие характеристики: имя, например. Фамилия, Имя, Отчество, Дата рождения; тип, например, символьный, числовой, календарный; длина, например, 15 байт, причем будет определяться максимально возможным количеством символов; точность для числовых данных, например два десятичных знака для отображения дробной части числа. Запись - совокупность логически связанных полей. Экземпляр записи - отдельная реализация записи, содержащая конкретные значения ее полей. Файл (таблица) - совокупность экземпляров записей одной структуры. В структуре записи файла указываются поля, значения которых являются ключами первичными (ПК), которые идентифицируют экземпляр записи, и вторичными (ВК), которые выполняют роль поисковых или группировочных признаков (по значению вторичного ключа можно найти несколько записей).
1.2 Вид моделей данных
Ядром любой базы данных является модель данных. Модель данных представляет собой множество структур данных, ограничений целостности и операций манипулирования данными. С помощью модели данных могут быть представлены объекты предметной области и взаимосвязи между ними. Модель данных - совокупность структур данных и операций их обработки. СУБД основывается на использовании иерархической, сетевой или реляционной модели, на комбинации этих моделей или на некотором их подмножестве. Рассмотрим три основных типа моделей данных: иерархическую, сетевую и реляционную.
Иерархическая модель данных
Иерархическая структура представляет совокупность элементов, связанных между собой по определенным правилам. Объекты, связанные иерархическими отношениями, образуют ориентированный граф (перевернутое дерево). К основным понятиям иерархической структуры относятся: уровень, элемент (узел), связь. Узел - это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа. Каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне. Иерархическое дерево имеет только одну вершину (корень дерева), не подчиненную никакой другой вершине и находящуюся на самом верхнем (первом) уровне. Зависимые (подчиненные) узлы находятся на втором, третьем и т.д. уровнях. Количество деревьев в базе данных определяется числом корневых записей. К каждой записи базы данных существует только один (иерархический) путь от корневой записи.
Сетевая модель данных
В сетевой структуре при тех же основных понятиях (уровень, узел, связь) каждый элемент может быть связан с любым другим элементом.
Реляционная модель данных
Понятие реляционный (англ. relation - отношение) связано с разработками известного американского специалиста в области систем баз данных Е. Кодда.
Эти модели характеризуются простотой структуры данных, удобным для
пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для обработки данных.
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
1. каждый элемент таблицы - один элемент данных;
2. все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;
3. каждый столбец имеет уникальное имя;
4. одинаковые строки в таблице отсутствуют;
5. порядок следования строк и столбцов может быть произвольным.
Отношения представлены в виде таблиц, строки которых соответствуют кортежам или записям, а столбцы - атрибутам отношений, доменам, полям.
Поле, каждое значение которого однозначно определяет соответствующую запись, называется простым ключом (ключевым полем). Если записи однозначно определяются значениями нескольких полей, то такая таблица базы данных имеет составной ключ.
Чтобы связать две реляционные таблицы, необходимо ключ первой таблицы ввести в состав ключа второй таблицы (возможно совпадение ключей); в противном случае нужно ввести в структуру первой таблицы внешний ключ - ключ второй таблицы.
1.3 Понятие информационного объекта
база данные информационный модель
Информационный объект - это описание некоторой сущности (реального объекта, явления, процесса, события) в виде совокупности логически связанных реквизитов (информационных элементов). Такими сущностями для информационных объектов могут служить: цех, склад, материал, вуз, студент, сдача экзаменов и т.д.
Информационный объект определенного реквизитного состава и структуры образует класс (тип), которому присваивается уникальное имя (символьное обозначение), например Студент, Сессия, Стипендия.
Информационный объект имеет множество реализации - экземпляров, каждый из которых представлен совокупностью конкретных значений реквизитов и идентифицируется значением ключа (простого - один реквизит или составного - несколько реквизитов). Остальные реквизиты информационного объекта являются описательными. При этом одни и те же реквизиты в одних информационных объектах могут быть ключевыми, а в других - описательными. Информационный объект может иметь несколько ключей.
1.4 Нормализация отношений
Понятие нормализации отношений
Одни и те же данные могут группироваться в таблицы (отношения) различными способами, т.е. возможна организация различных наборов отношений взаимосвязанных информационных объектов. Группировка атрибутов в отношениях должна быть рациональной, т.е. минимизирующей дублирование данных и упрощающей процедуры их обработки и обновления.
Определенный набор отношений обладает лучшими свойствами при включении, модификации, удалении данных, чем все остальные возможные наборы отношений, если он отвечает требованиям нормализации отношений. Нормализация отношений - формальный аппарат ограничений на формирование отношений (таблиц), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение (ввод, корректировку) базы данных.
Выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной) нормальной форме.
Первая нормальная форма
Отношение называется нормализованным или приведенным к первой нормальной форме, если все его атрибуты простые (далее неделимы). Преобразование отношения к первой нормальной форме может привести к увеличению количества реквизитов (полей) отношения и изменению ключа.
Например, отношение Студент = (Номер, Фамилия, Имя, Отчество, Дата, Группа) наводится в первой нормальной форме.
Вторая нормальная форма
Чтобы рассмотреть вопрос приведения отношений ко второй нормальной форме, необходимо дать пояснения к таким понятиям, как функциональная зависимость и полная функциональная зависимость. Описательные реквизиты информационного объекта логически связаны с общим для них ключом, эта связь носит характер функциональной зависимости реквизитов.
Функциональная зависимость реквизитов - зависимость, при которой экземпляре информационного объекта определенному значению ключевого реквизита соответствует только одно значение описательного реквизита. Такое определение функциональной зависимости позволяет при анализе всех взаимосвязей реквизитов предметной области выделить самостоятельные информационные объекты. В случае составного ключа вводится понятие функционально полной зависимости. Функционально полная зависимость не ключевых атрибутов заключается в том, что каждый не ключевой атрибут функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа. Отношение будет находиться во второй нормальной форме, если оно находится в первой нормальной форме, и каждый не ключевой атрибут функционально полно зависит от составного ключа.
Третья нормальная форма
Понятие третьей нормальной формы основывается на понятии нетранзитивной зависимости. Транзитивная зависимость наблюдается в том случае, если один из двух описательных реквизитов зависит от ключа, а другой описательный реквизит зависит от первого описательного реквизита. Отношение будет находиться в третьей нормальной форме, если оно находится во второй нормальной форме, и каждый неключевой атрибут нетранзитивно зависит от первичного ключа. Для устранения транзитивной зависимости описательных реквизитов необходимо провести «расщепление» исходного информационного объекта. В результате расщепления часть реквизитов удаляется из исходного информационного объекта и включается в состав других (возможно, вновь созданных) информационных объектов.
1.5 Типы связей
Все информационные объекты предметной области связаны между собой. Различаются связи нескольких типов, для которых введены следующие обозначения:
один к одному (1:1);
один ко многим (1: М);
многие ко многим (М: М).
Связь один к одному (1:1) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В и наоборот.
При связи один ко многим (1:М) одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с 1 экземпляром объекта А. Графически данное соответствие имеет вид.
Связь многие ко многим (М:М) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В и наоборот.
1.6 Модели данных
Сведенья о моделях данных
Инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель «сущность-связь» и т.д. Наиболее популярной из них оказалась модель «сущность-связь».
Инфологическая модель должна быть отображена в компьютеро - ориентированную даталогическую модель, «понятную» СУБД. В процессе развития теории и практического использования баз данных, а также средств вычислительной техники создавались СУБД, поддерживающие различные даталогические модели.
Сначала стали использовать иерархические даталогические модели. Простота организации, наличие заранее заданных связей между сущностями, сходство с физическими моделями данных позволяли добиваться приемлемой производительности иерархических СУБД на медленных ЭВМ с весьма ограниченными объемами памяти. Но, если данные не имели древовидной структуры, то возникала масса сложностей при построении иерархической модели и желании добиться нужной производительности.
Сетевые модели также создавались для мало ресурсных ЭВМ. Это достаточно сложные структуры, состоящие из «наборов» - поименованных двухуровневых деревьев. «Наборы» соединяются с помощью «записей-связок», образуя цепочки и т.д. При разработке сетевых моделей было выдумано множество «маленьких хитростей», позволяющих увеличить производительность СУБД. Но существенно усложнивших последние. Прикладной программист должен знать массу терминов, изучить несколько внутренних языков СУБД, детально представлять логическую структуру базы данных для осуществления навигации среди различных экземпляров, наборов, записей и т.п. Один из разработчиков операционной системы UNIX сказал: «Сетевая база - это самый верный способ потерять данные».
Сложность практического использования иерархических и сетевых СУБД заставляла искать иные способы представления данных. В конце 60-х годов появились СУБД на основе инвертированных файлов, отличающиеся простотой организации и наличием весьма удобных языков манипулирования данными. Однако такие СУБД обладают рядом ограничений на количество файлов для хранения данных, количество связей между ними, длину записи и количество ее полей.
Физическая организация данных оказывает основное влияние на эксплуатационные характеристики БД. Разработчики СУБД пытаются создать наиболее производительные физические модели данных, предлагая пользователям тот или иной инструментарий для поднастройки модели под конкретную БД. Разнообразие способов корректировки физических моделей современных промышленных СУБД не позволяет рассмотреть их в этом разделе.
Проектирование модели данных
Этапы проектирования данных
Предметная область - часть реального мира, подлежащая изучению с целью организации управления и, в конечном счете, автоматизации. Предметная область представляется множеством фрагментов, например, предприятие - цехами, дирекцией, бухгалтерией и т.д. Каждый фрагмент предметной области характеризуется множеством объектов и процессов, использующих объекты, а также множеством пользователей, характеризуемых различными взглядами на предметную область.
В теории проектирования информационных систем предметную область (или, если угодно, весь реальный мир в целом) принято рассматривать в виде трех представлений:
- представление предметной области в том виде, как она реально существует
- как ее воспринимает человек (имеется в виду проектировщик базы данных)
- как она может быть описана с помощью символов.
Т.е. говорят, что мы имеем дело с реальностью, описанием (представлением) реальности и с данными, которые отражают это представление.
Данные, используемые для описания предметной области, представляются в виде трехуровневой схемы (так называемая модель ANSI/SPARC):
Внешнее представление (внешняя схема) данных является совокупностью требований к данным со стороны некоторой конкретной функции, выполняемой пользователем. Концептуальная схема является полной совокупностью всех требований к данным, полученной из пользовательских представлений о реальном мире. Внутренняя схема - это сама база данных.
Отсюда вытекают основные этапы, на которые разбивается процесс проектирования базы данных информационной системы:
Концептуальное проектирование - сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:
- обследование предметной области, изучение ее информационной структуры
- выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами
- моделирование и интеграция всех представлений
По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели «сущность-связь».
Логическое проектирование - преобразование требований к данным в структуры данных. На выходе получаем СУБД-ориентированную структуру базы данных и спецификации прикладных программ. На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительный анализ моделей.
Физическое проектирование - определение особенностей хранения данных, методов доступа и т.д.
Различие уровней представления данных на каждом этапе проектирования представлено в следующей таблице:
Представление данных с помощью модели «сущность-связь»
Назначение модели
Прежде, чем приступать к созданию системы автоматизированной обработки информации, разработчик должен сформировать понятия о предметах, фактах и событиях, которыми будет оперировать данная система. Для того, чтобы привести эти понятиях той или иной модели данных, необходимо заменить их информационными представлениями. Одним из наиболее удобных инструментов унифицированного представления данных, независимого от реализующего его программного обеспечения, является модель «сущность-связь» (entity-relationship model, ER-model).
Модель «сущность-связь» основывается на некой важной семантической информации о реальном мире и предназначена для логического представления данных. Она определяет значения данных в контексте их взаимосвязи с другими данными. Важным является тот факт, что из модели «сущность-связь» могут быть порождены все существующие модели данных (иерархическая, сетевая, реляционная, объектная), поэтому она является наиболее общей.
Отметим, что модель «сущность-связь» не является моделью данных в строгом смысле, поскольку не определяет операций над данными и ограничивается описанием только их логической структуры.
Модель «сущность-связь» была предложена в 1976 г. Питером Пин-Шэн Ченом.
Элементы модели
Любой фрагмент предметной области может быть представлен как множество сущностей, между которыми существует некоторое множество связей. Дадим определения:
Сущность (entity) - это объект, который может быть идентифицирован неким способом, отличающим его от других объектов. Примеры: конкретный человек, предприятие, событие и т.д.
Набор сущностей (entity set) - множество сущностей одного типа (обладающих одинаковыми свойствами). Примеры: все люди, предприятия, праздники и т.д. Наборы сущностей не обязательно должны быть непересекающимися. Например, сущность, принадлежащая к набору МУЖЧИНЫ, также принадлежит набору ЛЮДИ.
Сущность фактически представляет из себя множество атрибутов, которые описывают свойства всех членов данного набора сущностей.
В дальнейшем для определения сущности и ее атрибутов будем использовать обозначение вида
СОТРУДНИК (ТАБЕЛЬНЫЙ_НОМЕР, ИМЯ, ВОЗРАСТ).
Например, отделы, на которые подразделяется предприятие, и в которых работают сотрудники, можно описать как ОТДЕЛ (НОМЕР_ОТДЕЛА, НАИМЕНОВАНИЕ).
Множество значений (область определения) атрибута называется доменом. Например, для атрибута ВОЗРАСТ домен (назовем его ЧИСЛО_ЛЕТ) задается интервалом целых чисел больших нуля, поскольку людей с отрицательным возрастом не бывает.
В упомянутой статье П. Чена атрибут определяется как функция, отображающая набор сущностей в набор значений или в декартово произведение наборов значений. Так атрибут ВОЗРАСТ производит отображение в набор значений (домен) ЧИСЛО_ЛЕТ. Атрибут ИМЯ производит отображение в декартово произведение наборов значений ИМЯ, ФАМИЛИЯ и ОТЧЕСТВО.
Отсюда определяется ключ сущности - группа атрибутов, такая, что отображение набора сущностей в соответствующую группу наборов значений является взаимнооднозначным отображением. Другими словами: ключ сущности - это один или более атрибутов, уникально определяющих данную сущность. В нашем примере ключом сущности СОТРУДНИК является атрибут ТАБЕЛЬНЫЙ_НОМЕР (конечно, только в том случае, если все табельные номера на предприятии уникальны).
Связь (relationship) - это ассоциация, установленная между несколькими сущностями. Примеры:
поскольку каждый сотрудник работает в каком-либо отделе, между сущностями СОТРУДНИК и ОТДЕЛ существует связь «работает в» или ОТДЕЛ-РАБОТНИК;
так как один из работников отдела является его руководителем, то между сущностями СОТРУДНИК и ОТДЕЛ имеется связь «руководит» или ОТДЕЛ-РУКОВОДИТЕЛЬ;
могут существовать и связи между сущностями одного типа, например связь РОДИТЕЛЬ - ПОТОМОК между двумя сущностями ЧЕЛОВЕК.
Следует отметить, что в методике проектирования данных есть своеобразное правило хорошего тона, согласно которому сущности обозначаются с помощью имен существительных, а связи - глагольными формами. Данное правило, однако, не является обязательным.
К сожалению, не существует общих правил определения, что считать сущностью, а что связью. В рассмотренном выше примере мы положили, что «руководит» - это связь. Однако, можно рассматривать сущность «руководитель», которая имеет связи «руководит» с сущностью «отдел» и «является» с сущностью «сотрудник».
Связь также может иметь атрибуты. Например, для связи ОТДЕЛ-РАБОТНИК можно задать атрибут СТАЖ_РАБОТЫ_В_ОТДЕЛЕ.
Роль сущности в связи - функция, которую выполняет сущность в данной связи. Например, в связи РОДИТЕЛЬ-ПОТОМОК сущности ЧЕЛОВЕК могут иметь роли «родитель» и «потомок». Указание ролей в модели «сущность-связь» не является обязательным и служит для уточнения семантики связи.
Набор связей (relationship set) - это отношение между n (причем n не меньше 2) сущностями, каждая из которых относится к некоторому набору сущностей.
Хотя, строго говоря, понятия «связь» и «набор связей» различны (первая является элементом второго), их, тем не менее, очень часто смешивают. Поэтому, в дальнейшем также будем часто пользоваться терминами «связь» имея в виду «набор связей» и «сущность» имея в виду «набор сущностей».
В случае n=2, т.е. когда связь объединяет две сущности, она называется бинарной. Доказано, что n-арный набор связей (n>2) всегда можно заменить множеством бинарных, однако первые лучше отображают семантику предметной области.
То число сущностей, которое может быть ассоциировано через набор связей с другой сущностью, называют степенью связи. Рассмотрение степеней особенно полезно для бинарных связей. Могут существовать следующие степени бинарных связей:
Один к одному (обозначается 1: 1). Это означает, что в такой связи сущности с одной ролью всегда соответствует не более одной сущности с другой ролью. В рассмотренном нами примере это связь «руководит», поскольку в каждом отделе может быть только один начальник, а сотрудник может руководить только в одном отделе. Данный факт представлен на следующем рисунке, где прямоугольники обозначают сущности, а ромб - связь. Так как степень связи для каждой сущности равна 1, то они соединяются одной линией.
Другой важной характеристикой связи помимо ее степени является класс принадлежности входящих в нее сущностей или кардинальность связи. Так как в каждом отделе обязательно должен быть руководитель, то каждой сущности «ОТДЕЛ» непременно должна соответствовать сущность «СОТРУДНИК». Однако, не каждый сотрудник является руководителем отдела, следовательно в данной связи не каждая сущность «СОТРУДНИК» имеет ассоциированную с ней сущность «ОТДЕЛ».
Таким образом, говорят, что сущность «СОТРУДНИК» имеет обязательный класс принадлежности (этот факт обозначается также указанием интервала числа возможных вхождений сущности в связь, в данном случае это 1,1), а сущность «ОТДЕЛ» имеет необязательный класс принадлежности (0,1). Теперь данную связь мы можем описать как 0,1:1,1. В дальнейшем кардинальность бинарных связей степени 1 будем обозначать следующим образом:
Один ко многим (1: n). В данном случае сущности с одной ролью может соответствовать любое число сущностей с другой ролью. Такова связь ОТДЕЛ-СОТРУДНИК. В каждом отделе может работать произвольное число сотрудников, но сотрудник может работать только в одном отделе. Графически степень связи n отображается «древообразной» линией, так это сделано на следующем рисунке.
Данный рисунок дополнительно иллюстрирует тот факт, что между двумя сущностями может быть определено несколько наборов связей.
Здесь также необходимо учитывать класс принадлежности сущностей. Каждый сотрудник должен работать в каком-либо отделе, но не каждый отдел (например, вновь сформированный) должен включать хотя бы одного сотрудника. Поэтому сущность «ОТДЕЛ» имеет обязательный, а сущность «СОТРУДНИК» необязательный классы принадлежности. Кардинальность бинарных связей степени n будем обозначать так:
Много к одному (n: 1). Эта связь аналогична отображению 1: n. Предположим, что рассматриваемое нами предприятие строит свою деятельность на основании контрактов, заключаемых с заказчиками. Этот факт отображается в модели «сущность-связь» с помощью связи КОНТРАКТ-ЗАКАЗЧИК, объединяющей сущности КОНТРАКТ (НОМЕР, СРОК_ИСПОЛНЕНИЯ, СУММА) и ЗАКАЗЧИК (НАИМЕНОВАНИЕ, АДРЕС). Так как с одним заказчиком может быть заключено более одного контракта, то связь КОНТРАКТ-ЗАКАЗЧИК между этими сущностями будет иметь степень n: 1.
В данном случае, по совершенно очевидным соображениям (каждый контракт заключен с конкретным заказчиком, а каждый заказчик имеет хотя бы один контракт, иначе он не был бы таковым), каждая сущность имеет обязательный класс принадлежности.
Многие ко многим (n: n). В этом случае каждая из ассоциированных сущностей может быть представлена любым количеством экземпляров. Пусть на рассматриваемом нами предприятии для выполнения каждого контракта создается рабочая группа, в которую входят сотрудники разных отделов. Поскольку каждый сотрудник может входить в несколько (в том числе и ни в одну) рабочих групп, а каждая группа должна включать не менее одного сотрудника, то связь между сущностями СОТРУДНИК и РАБОЧАЯ_ГРУППА имеет степень n: n.
Если существование сущности x зависит от существования сущности y, то x называется зависимой сущностью (иногда сущность x называют «слабой», а «сущность» y - сильной).
В качестве примера рассмотрим связь между ранее описанными сущностями РАБОЧАЯ_ГРУППА и КОНТРАКТ. Рабочая группа создается только после того, как будет подписан контракт с заказчиком, и прекращает свое существование по выполнению контракта. Таким образом, сущность РАБОЧАЯ_ГРУППА является зависимой от сущности КОНТРАКТ. Зависимую сущность будем обозначать двойным прямоугольником, а ее связь с сильной сущностью линией со стрелкой:
Заметим, что кардинальность связи для сильной сущности всегда будет (1,1). Класс принадлежности и степень связи для зависимой сущности могут быть любыми. Предположим, например, что рассматриваемое нами предприятие пользуется несколькими банковскими кредитами, которые представляются набором сущностей: КРЕДИТ (НОМЕР_ДОГОВОРА, СУММА, СРОК_ПОГАШЕНИЯ, БАНК). По каждому кредиту должны осуществляться выплаты процентов и платежи в счет его погашения. Этот факт представляется набором сущностей ПЛАТЕЖ (ДАТА, СУММА) и набором связей «осуществляется по». В том случае, когда получение запланированного кредита отменяется, информация о нем должна быть удалена из базы данных. Соответственно, должны быть удалены и все сведения о плановых платежах по этому кредиту. Таким образом, сущность ПЛАТЕЖ зависит от сущности КРЕДИТ.
2. Конструкторская часть
В данном курсовом проекте поставлена задача создания небольшой базы учета автотранспорта и дорожных механизмов. С помощью базы можно вести учет автотранспорта и механизмов в разбросанных автомобильных базах одного предприятия. Предусмотрена работа в многопользовательском файл-серверном варианте, когда таблицы с данными лежат на сервере, а у пользователей находятся клиентские части с исполняемым кодом. Поскольку база работает в основном на вывод данных, никаких специальных мер по блокировке записей не принималось. В параметрах, на закладке «Другие» устанавливалась блокировка изменяемой записи. Интерес представляет «Справочник типов автомобилей». Он позволяет организовать и изменять порядок вывода типов автомобилей и механизмов в соответствии с требованиями нормативов. В форме «Ввод, корректировка и вывод данных», интерес может представлять построитель запроса на выборку, который вызывается по кнопке «Выборка», и задание сортировки выводимой информации - кнопка «Сортировка».
Все пользователи базы разделены на 3 группы: администраторы, пользователи и зрители (или гости).
· Администратор может вводить, корректировать и распечатывать данные; просматривать и корректировать справочники; добавлять и удалять пользователей из списка доступа, а так же менять их привилегии.
· Пользователь может вводить, корректировать и распечатывать данные; просматривать и корректировать справочники.
· Гости могут просматривать различные данные из базы, но не могут редактировать информацию.
В данном примере первоначально зарегистрированы три пользователя с разными привилегиями: Имя - Пароль - Уровень
· Sasha 1 администратор
· Anton 1 пользователь
· Vera 1 зритель
К курсовому проекту прилагается сама база, которая состоит из трех основных файлов:
· Автотранспорт.mdb - клиентский модуль с исполняемым кодом
· Автотранспорт_Табл.mdb - база данных с таблицами
· Автотранспорт.hlp - файл справки к программе
Вид самой базы изнутри, можно просматривать отчеты различных дочерних организаций, сортировать и делать другие операции с данными.
Заключение
На сегодняшний день реляционные базы данных остаются самыми распространенными, благодаря своей простоте и наглядности как в процессе создания так и на пользовательском уровне. С помощью единственного запроса на этом языке можно соединить несколько таблиц во временную таблицу и вырезать из нее требуемые строки и столбцы (селекция и проекция). Так как табличная структура реляционной базы данных интуитивно понятна пользователям, то и язык SQL является простым и легким для изучения. Реляционная модель имеет солидный теоретический фундамент, на котором были основаны эволюция и реализация реляционных баз данных. На волне популярности, вызванной успехом реляционной модели, SQL стал основным языком для реляционных баз данных. В процессе анализа вышеизложенной информации выявлены следующие недостатки рассмотренной модели баз данных: - так как все поля одной таблицы должны содержать постоянное число полей заранее определенных типов, приходится создавать дополнительные таблицы, учитывающие индивидуальные особенности элементов, при помощи внешних ключей. Такой подход сильно усложняет создание сколько-нибудь сложных взаимосвязей в базе данных; - высокая трудоемкость манипулирования информацией и изменения связей.
Список использованной литературы
1. Кириллов И., Основы проектирования реляционных баз данных, 2008
2. Горев А., Эффективная работа с СУБД, 2007
3. Вейскас Д., Эффективная работа с Microsoft Access, 2010
4. Журнал «КомпьюТерра» №107-108 2004.
5. Потапкин А.В., Основы Visual Basic для пакета Microsoft Office, 2006
6. Фанниг Э., Базы данных: построение и эксплуатация, 2003
Размещено на Allbest.ru
Подобные документы
Понятие базы данных, ее архитектура. Классификация баз данных. Основные модели данных. Примеры структурированных и неструктурированных данных. Достоинства и недостатки архитектуры файл-сервер. Иерархическая модель данных. Виды индексов, нормализация.
презентация [1,4 M], добавлен 06.08.2014Классификация моделей построения баз данных. Работа с реляционными базами данных: нормализация таблиц, преобразование отношений полей, преобразование функциональной модели в реляционную. Понятие языка определения данных и языка манипуляции данными.
реферат [123,0 K], добавлен 22.06.2011Этапы проектирования базы данных, определение целей и содержание таблиц. Добавление данных и создание других объектов базы данных. Даталогическая модель: структуризация, нормализация, схемы данных. Порядок, принципы создания пользовательского интерфейса.
курсовая работа [1,3 M], добавлен 26.03.2013Понятие информации, автоматизированных информационных систем и банка данных. Общая характеристика описательной модели предметной области, концептуальной модели и реляционной модели данных. Анализ принципов построения и этапы проектирования базы данных.
курсовая работа [1,7 M], добавлен 18.01.2012Понятие нормализации таблиц базы данных и ее цели. Этапы процесса нормализации. Пример ненормализованных данных. Нормальные формы, к которым приводятся таблицы. Реляционная алгебра над учебной базой. База данных для предметной области "Учебные пособия".
контрольная работа [216,1 K], добавлен 30.07.2010Сущность и функциональные особенности баз данных, их классификация и типы, внутренняя структура и элементы. Модели данных, хранящихся в базах: иерархическая, сетевая, реляционная, многомерная, объектно-ориентированная. Виды запросов и типы таблиц.
дипломная работа [66,7 K], добавлен 06.01.2014Базы данных с двумерными файлами и реляционные системы управления базами данных (СУБД). Создание базы данных и обработка запросов к ним с помощью СУБД. Основные типы баз данных. Базовые понятия реляционных баз данных. Фундаментальные свойства отношений.
реферат [57,1 K], добавлен 20.12.2010Понятие и структура банка данных. Основные структурные элементы базы данных. Система управления базами данных. Преимущества централизации управления данными. Понятие информационного объекта. Современные технологии, используемые в работе с данными.
курсовая работа [1,8 M], добавлен 02.07.2011Авторизация с каталогами проектирования базы данных магазина. Задачи базы данных: учет всех товаров, поиск и выдача данных о клиентах, адрес, телефоны, цена и наличие товара. Этапы проектирования базы данных. Схема данных, создание запросов и их формы.
реферат [1,6 M], добавлен 22.10.2009Понятие базы данных, модели данных. Классификация баз данных. Системы управления базами данных. Этапы, подходы к проектированию базы данных. Разработка базы данных, которая позволит автоматизировать ведение документации, необходимой для деятельности ДЮСШ.
курсовая работа [1,7 M], добавлен 04.06.2015
