Размещено на http://www.allbest.ru/

Содержание

• Содержание.
• Введение.
• 1. Что такое базы данных и СУБД
• 1.1 Концепция баз данных
• 1.2 Модели данных
• 2. Инфологическая модель данных
• 2.1 Основные понятия
• 2.2 Классификация сущностей
• 2.3 О построении инфологической модели
• 3. Проектирование базы данных.
• 3.1 Описание БД “Автосалон иномарок”.
• 3.2 Инфологическая модель.
• 3.3 Даталогическая модель.
• 3.4 Разработка системного меню.
• 3.5 Разработка структуры программы.
• 3.6 Описанием процедур.
• 3.7 Описание интерфейса программы.
• 3.8 Листинг программы.
• Заключение.
• Список литературы.

Введение

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

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

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

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

1. Что такое базы данных и СУБД

1.1 Концепция баз данных

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

Основная особенность СУБД - это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем "Базы данных" (БД).

1.2 Модели данных

Инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д.. Наиболее популярной из них оказалась модель "сущность-связь", которая будет рассмотрена в главе 2. Инфологическая модель должна быть отображена в компьютеро-ориентированную даталогическую модель, "понятную" СУБД. В процессе развития теории и практического использования баз данных, а также средств вычислительной техники создавались СУБД, поддерживающие различные даталогические модели. Сначала стали использовать иерархические даталогические модели. Простота организации, наличие заранее заданных связей между сущностями, сходство с физическими моделями данных позволяли добиваться приемлемой производительности иерархических СУБД на медленных ЭВМ с весьма ограниченными объемами памяти. Но, если данные не имели древовидной структуры, то возникала масса сложностей при построении иерархической модели и желании добиться нужной производительности.

Сетевые модели также создавались для мало ресурсных ЭВМ. Это достаточно сложные структуры, состоящие из "наборов" - поименованных двухуровневых деревьев. "Наборы" соединяются с помощью "записей-связок", образуя цепочки и т.д. При разработке сетевых моделей было выдумано множество "маленьких хитростей", позволяющих увеличить производительность СУБД, но существенно усложнивших последние. Прикладной программист должен знать массу терминов, изучить несколько внутренних языков СУБД, детально представлять логическую структуру базы данных для осуществления навигации среди различных экземпляров, наборов, записей и т.п. Один из разработчиков операционной системы UNIX сказал "Сетевая база - это самый верный способ потерять данные". Сложность практического использования иерархических и и сетевых СУБД заставляла искать иные способы представления данных. В конце 60-х годов появились СУБД на основе инвертированных файлов, отличающиеся простотой организации и наличием весьма удобных языков манипулирования данными. Однако такие СУБД обладают рядом ограничений на количество файлов для хранения данных, количество связей между ними, длину записи и количество ее полей. Физическая организация данных оказывает основное влияние на эксплуатационные характеристики БД. Разработчики СУБД пытаются создать наиболее производительные физические модели данных, предлагая пользователям тот или иной инструментарий для поднастройки модели под конкретную БД. Разнообразие способов корректировки физических моделей современных промышленных СУБД не позволяет рассмотреть их в этом разделе.

2. Инфологическая модель данных

2.1 Основные понятия

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

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

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

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

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

Связь - ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных - это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.

2.2 Классификация сущностей

Настал момент разобраться в терминологии. К.Дейт определяет три основные класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей - обозначения.

Стержневая сущность (стержень) - это независимая сущность (несколько подробнее она будет определена ниже).

Ассоциативная сущность (ассоциация) - это связь вида "многие-ко-многим" ("-ко-многим" и т.д.) между двумя или более сущностями или экземплярами сущности. Ассоциации рассматриваются как полноправные сущности:

они могут участвовать в других ассоциациях и обозначениях точно так же, как стержневые сущности;

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

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

Для описания характеристики используется новое предложение ЯИМ, имеющее в общем случае вид:

ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2, ...)

Обозначающая сущность или обозначение - это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями и отличается от характеристики тем, что не зависит от обозначаемой сущности.

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

Описание обозначения внешне отличается от описания характеристики только тем, что обозначаемые сущности заключается не в фигурные скобки, а в квадратные:

ОБОЗНАЧЕНИЕ (атрибут 1, атрибут 2, ...)[СПИСОК

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

база данное программа модель

2.3 О построении инфологической модели

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

3. Проектирование базы данных

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

Инфологическая модель строится первая, затем на её основе строится Даталогическая модель. Физическая и внешняя модель после этого могут строится в любой последовательности.

3.1 Описание БД “Автосалон иномарок”

Рассмотрим задачу создания ДБ на примере простого электронного каталога автомобилей. Для каждого автомобиля записывается его название,

Фирма производитель, цена и т.д. и т.п.

3.2 Инфологическая модель.

В общем виде для данной курсовой работы инфологическая модель будет выглядеть следующим образом.

Размещено на http://www.allbest.ru/

Следует заметить, что между классами “Фирма продавец” и

“ Название автомобиля” связь 1:М. Рассмотрим отдельно каждый класс:

1) Класс «Фирма продавец»



3) Класс «Автомобиль»



3.3 Даталогическая модель

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

Класс «Фирма продавец» 4 поля

Файл Office.db

Название фирмы	Код	Адрес	Телефон	@E-mail
A-10	I	A	T	A

2)Класс «Автомобиль» 10-полей

Файл Auto.db

Название автомобиля	Фирма производитель	Цена $	Люк	Гидроусилитель руля
A-25	A- 20	N	A-3	A-3

Аудио система	Сигнализация	Литые диски	Код автомобиля	Фотография
A-3	A-3	A-3	N	A-100

3) Файл TehnHar.db 8-полей

Код автомобиля	Тип кузовава	Число цилиндров	Мощность	Рабочий объем
I	A-10	N	N	N

Скорость	Разгон 0-100км/ч.	Код автомобиля
N	N	I

3.4 Разработка системного меню

В разработанной мною программе имеется следующая схема системного меню.

Выбор соответствующего пункта меню определяет действия производимые с БД в соответствии с названием пункта.

При выборе меню «Файл» «Режим редактирования» данный подпункт меню предназначен для редактирования БД, добавления, удаления и изменения записей.

При выборе меню «Файл» «Режим просмотра» данный режим предназначен только для просмотра содержимого БД , при нем запрещено редактирование данных.

Для удобства пользователя задействованный режим выделен жирным шрифтом.

При выборе меню «Файл» «Выход» приложение закрывается.

3.5 Разработка структуры программы

Размещено на http://www.allbest.ru/

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

БД Выводимая информация

3.6 Описанием процедур

Процедура удаления записи из базы данных .

procedure TForm1.RestoreColors(Sender: TObject; Shift: TShiftState; X,

Y: Integer);

begin

SpeedButton1.Font.Color:=clYellow;

SpeedButton2.Font.Color:=clYellow;

SpeedButton3.Font.Color:=clYellow;

SpeedButton4.Font.Color:=clYellow;

SpeedButton5.Font.Color:=clYellow;

end;

Процедура вставки записи в тпблицу

procedure TForm1.SpeedButton1Click(Sender: TObject);

begin

AutoTable.Insert;

end;

Процедура удаления записи из базы данных .

procedure TForm1.SpeedButton2Click(Sender: TObject);

begin

If MessageDlg('Вы действительно хотите удалить запись?',

mtConfirmation, [mbYes, mbNo], 0) = mrYes

Then If MessageDlg('А может ненадо?',mtConfirmation,

[mbYes, mbNo], 0) = mrYes

Then AutoTable.Delete;

end;

Процедура поиска записи и загрузки BMP-файла

procedure TForm1.DBGrid1CellClick(Column: TColumn);

Var

IndexCode : Integer;

begin

IndexCode:=AutoTable['Код'];

TehnHar.Open;

TehnHar.First;

Office.Open;

Office.First;

TehnHar.Locate('Код',IndexCode,[loCaseInsensitive]);

Office.Locate('Код',IndexCode,[loCaseInsensitive]);

If FileExists(DbEdit1.Text) Then Begin

Image1.Picture.LoadFromFile(DbEdit1.Text);

Image2.Picture.LoadFromFile(DbEdit1.Text);

End

Else MessageDlg('Картинка не найдена',mtConfirmation,[mbNo], 0);

end;

3.7 Описание интерфейса программы

Программа очень удобна тем, что на одной форме размещено большое количество информации. Это достигнуто использованием компонента Delphi 3. На форме размещены пять закладок с заголовками характеризующими содержимое данной закладки.



При просмотре закладки «О программе...» можно получить информацию о приложении

Щелкнув на «Автомобиль» можно получить информацию об автомобиле его технических характеристиках, фирме продаваемой данный автомобиль и виде модели

Приведем пример использования поиска в таблице



3.8 Листинг программы

unit Unit1;

interface

uses

Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,

ComCtrls, Menus, StdCtrls, Grids, DBGrids, Db, DBTables, ExtCtrls,

DBCtrls, Buttons, Mask;

type

TForm1 = class(TForm)

My: TPageControl; Auto: TTabSheet; Offis: TTabSheet; TabSheet3: TTabSheet; MainMenu1: TMainMenu; N1: TMenuItem; N2: TMenuItem;

AutoDS1: TDataSource; AutoTable: TTable; DBGrid1: TDBGrid;

TabSheet1: TTabSheet; Bevel1: TBevel; Label1: TLabel; SpeedButton1: TSpeedButton; SpeedButton2: TSpeedButton; Bevel2: TBevel; SpeedButton3: TSpeedButton; Image_O_Program: TImage; Bevel3: TBevel; Bevel4: TBevel;

Bevel5: TBevel; DBEdit1: TDBEdit; Label6: TLabel; Label7: TLabel;

Label8: TLabel; Image1: TImage;TehnHarDS1: TDataSource; TehnHar: TTable;

TabSheet2: TTabSheet; DBGrid2: TDBGrid; Bevel6: TBevel; DBEdit2: TDBEdit;

DBEdit3: TDBEdit; DBEdit4: TDBEdit; DBEdit5: TDBEdit; DBEdit6: TDBEdit;

DBEdit7: TDBEdit; Bevel7: TBevel; DBEdit8: TDBEdit; Label2: TLabel;

Label3: TLabel; Label4: TLabel; Label5: TLabel; Label9: TLabel;

Label10: TLabel; Label11: TLabel; DBText1: TDBText; DBText2: TDBText;

Bevel8: TBevel;Bevel9: TBevel;SpeedButton4: TSpeedButton; SpeedButton5: TSpeedButton;N3: TMenuItem;N4: TMenuItem;Label12: TLabel;office: TTable;

DSOffice: TDataSource;DBGrid3: TDBGrid; Bevel10: TBevel; Bevel11: TBevel;

Memo1: TMemo;Memo2: TMemo;DBEdit9: TDBEdit;Label13: TLabel;

Bevel12: TBevel; Image2: TImage; Bevel13: TBevel;

procedure N2Click(Sender: TObject);

procedure ChengColor(Sender: TObject; Shift: TShiftState; X,

Y: Integer);

procedure restoreColors(Sender: TObject; Shift: TShiftState; X,

Y: Integer);

procedure SpeedButton1Click(Sender: TObject);

procedure SpeedButton2Click(Sender: TObject);

procedure Form1OnCreat(Sender: TObject);

procedure SpeedButton4Click(Sender: TObject);

procedure DBGrid1CellClick(Column: TColumn);

procedure SpeedButton3Click(Sender: TObject);

procedure SpeedButton5Click(Sender: TObject);

procedure N3Click(Sender: TObject);

procedure N4Click(Sender: TObject);

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form1 : TForm1;

PredIndex : Longint;

implementation

uses Unit2;

{$R *.DFM}

procedure TForm1.N2Click(Sender: TObject);

begin

Close;

end;

procedure TForm1.ChengColor(Sender: TObject; Shift: TShiftState; X,

Y: Integer);

begin

RestoreColors(Sender,Shift,X,Y);

(Sender as TSpeedButton).Font.Color:=clAqua;

end;

procedure TForm1.RestoreColors(Sender: TObject; Shift: TShiftState; X,

Y: Integer);

begin

SpeedButton1.Font.Color:=clYellow;

SpeedButton2.Font.Color:=clYellow;

SpeedButton3.Font.Color:=clYellow;

SpeedButton4.Font.Color:=clYellow;

SpeedButton5.Font.Color:=clYellow;

end;

Процедура вставки записи в тпблицу

procedure TForm1.SpeedButton1Click(Sender: TObject);

begin

AutoTable.Insert;

end;

procedure TForm1.SpeedButton2Click(Sender: TObject);

begin

If MessageDlg('Вы действительно хотите удалить запись?',

mtConfirmation, [mbYes, mbNo], 0) = mrYes

Then If MessageDlg('А может ненадо?',mtConfirmation,

[mbYes, mbNo], 0) = mrYes

Then AutoTable.Delete;

end;

procedure TForm1.Form1OnCreat(Sender: TObject);

begin

PredIndex:=1;

end;

procedure TForm1.SpeedButton4Click(Sender: TObject);

Begin

TehnHar.Insert;

end;

procedure TForm1.DBGrid1CellClick(Column: TColumn);

Var

IndexCode : Integer;

begin

IndexCode:=AutoTable['Код'];

TehnHar.Open;

TehnHar.First;

Office.Open;

Office.First;

TehnHar.Locate('Код',IndexCode,[loCaseInsensitive]);

Office.Locate('Код',IndexCode,[loCaseInsensitive]);

If FileExists(DbEdit1.Text) Then Begin

Image1.Picture.LoadFromFile(DbEdit1.Text);

Image2.Picture.LoadFromFile(DbEdit1.Text);

End

Else MessageDlg('Картинка не найдена',mtConfirmation,[mbNo], 0);

end;

procedure TForm1.SpeedButton3Click(Sender: TObject);

begin

Form2.ShowModal;

end;

procedure TForm1.SpeedButton5Click(Sender: TObject);

begin

If MessageDlg('Вы действительно хотите удалить запись?',

mtConfirmation, [mbYes, mbNo], 0) = mrYes

Then If MessageDlg('А может ненадо?',mtConfirmation,

[mbYes, mbNo], 0) = mrYes

Then TehnHar.Delete;

end;

procedure TForm1.N3Click(Sender: TObject);

begin

DBGrid1.ReadOnly:=false;

DbGrid2.ReadOnly:=false;

N3.Default:=true;

end;

procedure TForm1.N4Click(Sender: TObject);

begin

DBGrid1.ReadOnly:=true;

DbGrid2.ReadOnly:=true;

N4.Default:=true;

end;

end.

Заключение

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

Список литературы

А.М. Епанешников. Программирование в среде Delphi .

Джон Вейскас Эффективная работа в Access 97.

Марко Канту Delphi для профессионалов 99.

Журнал « Клаксон » 09.99г.

Размещено на Allbest.ru