Проектирование и реализация базы данных

    Содержание

    Введение…………………………………………………………………...…3

    Глава 1. Основные понятия БД и СУБД ………………………..……….....4

1. Данные  и ЭВМ……………………………………………...…....……4

2. Архитектура СУБД………………………………………...………….6

3. Модели данных…………………………………………………...…...9

    Глава 2. Инфологическая модель данных "Сущность-связь"………..….11

1. Основные  понятия………………………………………………...…..11

2. Характеристика  связей и язык моделирования………………….….13

3. Классификация сущностей…………………………………………...15

4. Первичные и внешние ключи………………………………………..17

5. Ограничения целостности………………………………………...….22

    Глава 3. Реляционный подход………………………………………….…24

1. Реляционная структура данных……………………………...………24

2. Реляционная база данных……………………………………...……..27

3. Манипулирование реляционными данными…………………….….29

Глава 4. Проектирование и реализация базы данных……………………30

       4.1 Проектирование концептуальной модели базы данных……………...30

       4.2 Проектирование логической модели базы данных…………………...32

       4.3 Реализация базы данных в СУБД MS Access…………………………..36

Заключение………………………………………………………………….44

Список используемой литературы………………………………………...45

 

Введение

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

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

    Задачами  данной работы являются:

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

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

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

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

 

     Глава 1.  Основные понятия БД и СУБД

1.   Данные и ЭВМ

    Восприятие  реального мира можно соотнести  с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать  эти явления (даже тогда, когда не могли их понять). Такое описание называют данными.

    Традиционно фиксация данных осуществляется с помощью конкретного средства общения (например, с помощью естественного языка или изображений) на конкретном носителе (например, камне или бумаге). Обычно данные (факты, явления, события, идеи или предметы) и их интерпретация (семантика) фиксируются совместно, так как естественный язык достаточно гибок для представления того и другого. Примером может служить утверждение "Стоимость авиабилета 128". Здесь "128" – данное, а "Стоимость авиабилета" – его семантика.

    Нередко данные и интерпретация разделены. Например, "Расписание движения самолетов" может быть представлено в виде таблицы , в верхней части которой (отдельно от данных) приводится их интерпретация. Такое разделение затрудняет работу с данными (трудно быстро получить сведения из нижней части таблицы).

    Применение  ЭВМ для ведения и обработки данных обычно приводит к еще большему разделению данных и интерпретации. ЭВМ имеет дело главным образом с данными как таковыми. Большая часть интерпретирующей информации вообще не фиксируется в явной форме (ЭВМ не "знает", является ли "21.50" стоимостью авиабилета или временем вылета). Почему же это произошло?

    Существует  по крайней мере две исторические причины, по которым применение ЭВМ  привело к отделению данных от интерпретации. Во-первых, ЭВМ не обладали достаточными возможностями для обработки текстов на естественном языке – основном языке интерпретации данных. Во-вторых, стоимость памяти ЭВМ была первоначально весьма велика. Память использовалась для хранения самих данных, а интерпретация традиционно возлагалась на пользователя. Пользователь закладывал интерпретацию данных в свою программу, которая "знала", например, что шестое вводимое значение связано с временем прибытия самолета, а четвертое – с временем его вылета. Это существенно повышало роль программы, так как вне интерпретации данные представляют собой не более чем совокупность битов на запоминающем устройстве.

    Жесткая зависимость между данными и  использующими их программами создает  серьезные проблемы в ведении  данных и делает использования их менее гибкими.

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

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

2. Архитектура СУБД

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

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

    и множестве других функций СУБД.

    При выполнении основных из этих функций  СУБД должна использовать различные  описания данных. А как создавать  эти описания?

    Естественно, что проект базы данных надо начинать с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). Подробнее этот процесс будет рассмотрен ниже, а здесь отметим, что проектирование обычно поручается человеку (группе лиц) – администратору базы данных (АБД). Им может быть как специально выделенный сотрудник организации, так и будущий пользователь базы данных, достаточно хорошо знакомый с машинной обработкой данных.

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

    

    Рисунок 1  Уровни моделей  данных

    Такая человеко-ориентированная модель полностью  независима от физических параметров среды хранения данных. В конце концов этой средой может быть память человека, а не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.

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

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

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