Форум Сообщества Аналитиков
Дисциплины => Проектирование => Тема начата: Galogen от 30 Марта 2007, 11:22:16
-
Уважаемые коллеги!
Хотел с вами посоветоваться по вопросу проектирования одной базы данных, вернее для начала моделирование простой предметной области.
Краткое описание в виде фактов
1. Каждый студент учится в одной и только одной группе
2. Группа включает множество студентов, обычно в некотором предельном диапазоне x<=N<=y
3. Группа имеет номер, состоящий из номера группы(специализации) и номера курса 1-33, 2-42, 4-56, 5-56, 4-33
4. Студенты группы по итогам сессии переводятся на следующий курс: была 1-33 стала 2-33, а студенты вообщем остались :-)
4. Студенты группы в сессию должны сдать ряд экзаменов по предметам. Количество экзаменов ограничено обычно 4-5 за сессию (однако надо понимать, что по каждому изучаемому в течение семестра предмету должна быть выставлена итоговая оценка: зачет, диф.зачет, курсовая, экзамен) В данной задаче мы рассматриваем только результаты экзаменов!
5. оценка может принимать значение 2, 3, 4, 5 и неопределена (то есть студент экзамен не сдавал)
В результате я создал две модели
1. модель концептуальная
2. тоже но с использованием суррогатных ключей
Хотелось бы услышать замечания, пожелания, советы, другие варианты модели данных.
Для большей результативности опишу то что хотелось бы видеть в конечном приложении.
1 форма - Результаты экзаменов: Фио студента, Предмет, Оценка по предмету
2 форма - Список студентов - ФИО студента, Номер группы
3 форма - Группы - Курс, Номер группы
4 форма - Предметы - Название предмета
5 форма - Экзамены по предметам - Номер группы, Название предмета
-
Я бы еще добавлил Студент -- Курс -- Группа
-
Я бы еще добавлил Студент -- Курс -- Группа
Тогда уж Курс - (М) Группа - (М) Студент
На самом деле это не так важно, поскольку переход на курс одной и той же группы вряд ли имеет смысл завязывать на ссылочную целосность
в обоих вариантах есть некоторая проблема, сначала надо перевести все группы с последнего курса на некий гипотетический 6, а затем по нисходящей изменить курсы у других.
Можно сделать проще - хранить год поступления т.е. пара год поступления и номер группы уникальны, тогда отображаемый номер группы в стиле Курс-Номер группа будет определяться в приложении, либо автоматом меняться в определенный момент времени
Пока эта ситуация в задаче не актуальна...
-
Ну да, что-то я перепутал группу с факультетом ...
-
Эдуард, а чего ты не стал рисовать в UML?
Сразу видно, что у группы неправильно выбран ключ, он зависит от времени. Группа 1-46, учившаяся в 96-м году и группа 1-46, учившаяся в 2001-м году - это разные группы. Получается, ты должен будешь стирать из БД выпускников и ежегодно обновлять идентификаторы групп, переходящих с курса на курс.
Так что спокойно делай идентификатором код специальности и год формирования группы, а курс - атрибутом, возможно производным.
Не понял, почему ты в тексте говоришь "Экзамен", а в диаграмме только "Сессия". Сессия имеет атрибуты - Год и Время года (Зимняя/Летняя). Экзамен - это соответственно ключи на "Предмет", "Группа" и "Сессия", неключевой атрибут - дата проведения. Оценка - имеет ключи на Студент и Экзамен.
-
Денис, спасибо за ответ и интерес к теме.
Немного поясню предысторию вопроса.
Данная предметная область или лучше сказать исходные таблицы взяты из книги Карповой. "Базы данных". Из-во Питер.
На базе этого примера объясняются некоторые вопросы SQL.
Более того, данный пример положен в основу курса управления данными. Веду не я:-)
Мне с самого начала это пример не понравился. Он конечно не теряет значимости, то его роль ограничена. Тем не менее, положив его в основу курса, преподаватель на мой взгляд, создает предвзятое представление о проетировании БД и управлении данными
Исходная схема такова. Даны три таблицы. Или скорее отношения:
Студенты-Группы R1 (Фио студента, Номер группы)
Группы-Предметы R2 (Номер группы, Название предмета)
Итоги сесии R3 (Фио студента, Название предмета, Оценка)
Повторяю для определенных целей - скажем изучения SQL, такая схема вполне нормальна. Но она слишком оторвана от реальной практики на мой взгляд.
Я решил ее немного улучшить, без внесения особо сложных моментов. Таких как факт перехода с курса на курс. Хотя возможно, такое упрощение только вредит делу.
Кстати задачу можно решать и с помощью UML, если привязать сюда учебные аспекты связанные с использованием MDA (Delphi BOLD).
Твоя схема мне понравилась, надо внимательно ее изучить:-)
-
Хм, кажется тему кто-то подправил?
Кажется, имеет смысл сузить исходную задачу.
То есть я не ставлю себе целью получения такой модели данных, которая позволяет хранить и управлять информацией о всех экзаменационных сессиях.
Постулируем тот факт, что от сессии до сессии живут суденты весело, а сессия, а сессия всего два раз в год!
Итак 1 раз в полгода происходит заполнение некоторой БД фактами о сдачи экзаменов. Что бы не забираться в глубины предметной области и остаться на самом простом уровне восприятия задачи предположим, что результаты сессии - архивируются и помещаются на хранение, при архивировании во все сущности добавляется год и время года. Одновременно, происходит создание новой БД с переносом данных по студентам - группам (номер курса в номере группы у студентов увеличивается на 1). Тогда таблица скажем Группа-Предмет остается без изменения, т.к. она фактически хранит учебный план подготовки для каждой группы (вернее список предметов, которые должны вообще сдаваться за учебный год) Тогда наверное имеет смысл добавить атрибут: семестр.
Итак, имеющаяся "базовая" структура данных не устраивает тем, что при реализации приложения, программисту приходится довольно серьезно продумывать вопросы поддержания целостности. Например: при реализации формы Экзамены(итоги сессии) я к примеру делаю два поля - полями combobox - к ним lookup-таблица, соотвествующая. Эти поля есть ФИО и ПРЕДМЕТ. Какие сразу возникают проблемы:
1. В списке студентов ВСЕ студенты - а следовательно масса однофамильцев может быть (вводить скажем номер зачетки - выход из положения - но не хочется)
2. в списке предметов будут повторяющиеся предметы, если только не делать источником данных запрос
3. Никто не гарантирует, что студент группы 2-45, будет вдруг сдавать экзамен по предмету, который читают только для группы 5-45 или 1-23
Как можно разрешить проблему?
1. в combobox вытаскивать поле ФИО студента и Номер группы (№ группы - скрытое)
2. в combobox аналогично вытаскивать Предмет и Номер группы (№ группы скрытое)
Очевидно что лучше использовать не сами lookup-table а запросы параметрические.
Далее вешаем на combobox соотвествующие процедуры-события, когда при выборе чего-то в одном поле, второе поле автоматом фильтруется
Таким образом - задача в составление такой схемы БД, которая максимально полно использует стандартные механизмы поддержания целостности
-
Насчет ведомости.
Вне всякого сомнения такая сущность вполне могла бы существовать.
С другой стороны, ведомость есть некий документ или отчет, имеющий определенную структуру и являющийся результатом композиции данных.
Т.е. ведомость может формироваться как отчет.
Но это может быть и первичный документ с разными состояниями: черновик и учтена.
Черновик может формироваться автоматически, а перервод в состояние учетна будет происходить после, когда будет внесены оценки.
-
Кстати, надо отметить, что вопрос не имеет отношения к целостности. По моему тут как раз нечеткое представление о том, как лучше сделать интерфейсную часть. Вот если бы мы расписали бы сценарии для работы с формами, то можно было бы говорить о чем-то.
Во все нет. У меня вполне четкое представление об интерфейсной части. Тут нет никаких проблем.
Насчет целостности все достаточно прозрачно. Посмотрим на мои модели, они практически равнозначны.
Таблица связи между ГРУППОЙ и ПРЕДМЕТОМ фактически формирует список предметов, которые должна сдавать определенная группа. Эта промежуточная таблица соединена с таблицей СЕССИЯ, соотвественно по моему убеждению, в нею при выборе студента, будет попадать информация о предметах для которых группы совпадают. В этом я и вижу ораничение целостности
Мне, например, кажется, что в приведенном предложении выбирать фамилию студента из списка кроется нарушение принципа однократности ввода информации.
А вот этого тезиса не понял совсем. Какое такое нарушение принципа одноератности ввода тут нарушается. Поясни свои доводы, я их не понимаю
Смотри: мы имеем таблицу-сущность СТУДЕНТЫ(idstud, FIO)
ПРЕДМЕТЫ(idpred, Название)
Далее имеем отношение Итоги сессии(idstud, idpred, Оценка)
В форме я делаю для первых двух полей поля подстановки, подставляется то id, а отображается ФИО - никаого нарушения однократности ввода нет
-
Данная предметная область или лучше сказать исходные таблицы взяты из книги Карповой. "Базы данных". Из-во Питер. На базе этого примера объясняются некоторые вопросы SQL. Более того, данный пример положен в основу курса управления данными. Веду не я:-)
Мне с самого начала это пример не понравился. Он конечно не теряет значимости, то его роль ограничена. Тем не менее, положив его в основу курса, преподаватель на мой взгляд, создает предвзятое представление о проетировании БД и управлении данными
Исходная схема такова. Даны три таблицы. Или скорее отношения:
Студенты-Группы R1 (Фио студента, Номер группы)
Группы-Предметы R2 (Номер группы, Название предмета)
Итоги сесии R3 (Фио студента, Название предмета, Оценка)
Имеет место плохое понимание того, что есть отношения. (Фамилия, Имя, Отчество) уже образуют отношение. И отношение это называется Студент. То, что в силу мощности связи Студент-Группа 1-ко-многим имеет смысл в Отношение студент при переходе к таблицам добавить столбец-ссылку на Группу, не должно приводить к переименованию Отношения, а теперь таблицы Студент.
Повторяю для определенных целей - скажем изучения SQL, такая схема вполне нормальна. Но она слишком оторвана от реальной практики на мой взгляд.
Ой, так уж и нормальна. Попробуй в системе, построенной по такой модели, ответить на простой вопрос - "каково соотношение Иванов и Олегов среди студентов вуза?", "Сколько однофамильцев, сколько возможных братьев и сестёр?". А информация там есть.
Я решил ее немного улучшить, без внесения особо сложных моментов. Таких как факт перехода с курса на курс. Хотя возможно, такое упрощение только вредит делу.
Именно.
Кстати задачу можно решать и с помощью UML, если привязать сюда учебные аспекты связанные с использованием MDA (Delphi BOLD).
UML имеет ценность и без MDA, а как средство моделирования, способное выражать больше семантики, нежели ERM.
-
Кажется, имеет смысл сузить исходную задачу.
То есть я не ставлю себе целью получения такой модели данных, которая позволяет хранить и управлять информацией о всех экзаменационных сессиях.
В процессе концептуального моделирования предметной области имеет смысл выделить максимальное количество Классов, и только потом, при переходе к проектированию, сокращать их количество и всячески реорганизовывать.
Итак 1 раз в полгода происходит заполнение некоторой БД фактами о сдачи экзаменов. Что бы ... остаться на самом простом уровне восприятия задачи предположим, что результаты сессии - архивируются и помещаются на хранение, при архивировании во все сущности добавляется год и время года. Одновременно, происходит создание новой БД с переносом данных по студентам - группам (номер курса в номере группы у студентов увеличивается на 1).
Клёво, добавляются новые атрибуты, есть отдельное хранилище - архив, создаётся новая БД, туда переносятся данные - и всё это ты называешь упрощением? А не проще ли было добавить к Экзамену и Сессии атрибут Состояние, который для Экзамена будет принимать значения "Планируется", "Проведён", а для Сессии - "Планируется", "Активная", "Закрытая"? И переключая состояния, получать нужные выборки?
1. В списке студентов ВСЕ студенты - а следовательно масса однофамильцев может быть (вводить скажем номер зачетки - выход из положения - но не хочется)
Вообще-то экзамен сдаётся не каждым студентом по отдельности, а группой, поэтому к моменту указания студента группа уже должна быть выбрана.
Таким образом - задача в составление такой схемы БД, которая максимально полно использует стандартные механизмы поддержания целостности
Я бы сказал - задача просто правильно спроектировать БД :)
-
Возможно, чего-то не понимаю я. Если не трудно, нарисуй формы, о которых ты говоришь и напиши сценарий, кудпа жать и что получится.
Нарисованные тобою формы вполне подходят и первы и второй вариант. Пока используется первый, но естесвтенно оценки не выбираются из списка. На самом деле в этом нет необходимости
Проблему я вижу в том, что представление об интерфейсной части появились до представлений о сценарии работы пользователя и его интересах вообще.
Во все нет. Такого как раз не было. Однако такая иллюзия возникает потому, что исходная схема уже реализованная в учебном практическом задании.
Цель преподавания(сформулированная не мною) - ознакомить с основными приемам разработки приложения для работы с базой данных: собственно проектирование таблиц, создание форм разного назначения, формирование запросов, подключение внешних таблиц, внешние динамические соединения, отчеты. Т.е. упор делается на RAD. Инструмент FoxPro. К сожалению процессу не предшествует моделирование данных и исследование предметной области как таковой. Все что известно - это уже представленные отношения с неким набором данных. Концепция приложения - это уже выдумка преподавателя и его видение этой задачи. Я совсем не сомневаюсь в его компетенции, но какмне кажется вопросы управления данными через приложение маскируют важность задачи моделирования предметной области.
Примером тому ваша активная критика моих рассуждений.
Моя задача - не внося существенных изменений в предложенную схему, сделать ее более правильной и прозрачной для использования.
Ниже прилагаются формы приложения.
-
Имеет место плохое понимание того, что есть отношения. (Фамилия, Имя, Отчество) уже образуют отношение. И отношение это называется Студент.
Денис, мне не нравится такое утверждение: имеет место плохое понимание.
Во первых если ты внимательно изучил схему и мои записи, то я нигде не утвержадю что Студент это Фамилия, Имя, Отчество. Я пишу лишь, что студент это ФИО. А если студент имеет один атрибут ФИО - то это множество (вернее мультимножество, если учесть тезок, хотя для простоты задачи мы полагаем что нет полных тезок), а не отношение.
Я прекрасно понимаю, что такое отношение. И сущность по своей сути есть всегда отношение, так же как и связи между двумя сущностями называются бинарным отношением.
Ой, так уж и нормальна. Попробуй в системе, построенной по такой модели, ответить на простой вопрос - "каково соотношение Иванов и Олегов среди студентов вуза?", "Сколько однофамильцев, сколько возможных братьев и сестёр?". А информация там есть.
Не надо умножать сложности там где ее нет. А соотношение Иванов и Олегов при желании можно сделать и на существующей схеме. А пробратьев и сестер - это уже твои придумки.
Горе с этими аналитиками - сразу начинают навязывать тебе свое представление о мире, полагая, что их представление самое, что не на есть правильное:-)
Не нужно мне в данной задаче знать, братья али сестра, нет нужды знать сколько однофамильцев и сколько Олегов.
Нужно было бы так и было бы.
Еще раз говорю, документируется задача в пределах 1 сессии. Все - небольше, неменьше.
Никто не отрицает правильности всех ваших замечаний, если говорить о реальной предметной области и реальной задаче учета сессии, работы деканата (про работу деканата мы еще по говорим, но в другом месте:-)
UML имеет ценность и без MDA, а как средство моделирования, способное выражать больше семантики, нежели ERM.
Да не сомневаюсь я в ценности UML без MDA. Бог с тобой. Насчет семантической мощности тоже не спорю. ERM используется как инструмент, с которым студенты знакомы. А с UML еще пока нет
-
Вообще-то экзамен сдаётся не каждым студентом по отдельности, а группой, поэтому к моменту указания студента группа уже должна быть выбрана.
вообще-то оценку получет студент, а не группа. группа просто структурная единица определяющая набор дисциплин, по которым сдается экзамен студентом этой группы...
Я бы сказал - задача просто правильно спроектировать БД :)
Правильно, но исходя лишь из тех понятий, что я уже изложил.
-
Моя задача - не внося существенных изменений в предложенную схему, сделать ее более правильной и прозрачной для использования.
Тогда почему ты называешь тему "Проектирование БД", а не "Реинжиниринг БД", "Рефакторинг БД" или "Реорганизация БД"?
-
Горе с этими аналитиками - сразу начинают навязывать тебе свое представление о мире, полагая, что их представление самое, что не на есть правильное:-)
Причём тут представление о мире, если ты делаешь ФИО составным атрибутом, позволяя, таким образом, писать туда что попало, хоть только фамилию, хоть только фамилию и имя. О какой целостности данных может идти речь? Что проще - проверить, что поле заполнено, или проверить, что в поле есть 2 и только 2 отдельных пробела? Это та составляющая системы, которая называется "Качество данных", тема наcтолько важная для больших компаний, что некоторые даже свой бизнес только на этом создают (http://datacleaning.ru/).
Смотри рефакторинг БД под именем Split Column (http://www.agiledata.org/essays/databaseRefactoringCatalogStructural.html#SplitColumn).
-
Тогда почему ты называешь тему "Проектирование БД", а не "Реинжиниринг БД", "Рефакторинг БД" или "Реорганизация БД"?
Ну что пришло на ум, так и назвалось
-
Причём тут представление о мире, если ты делаешь ФИО составным атрибутом, позволяя, таким образом, писать туда что попало, хоть только фамилию, хоть только фамилию и имя. О какой целостности данных может идти речь? Что проще - проверить, что поле заполнено, или проверить, что в поле есть 2 и только 2 отдельных пробела? Это та составляющая системы, которая называется "Качество данных", тема наcтолько важная для больших компаний, что некоторые даже свой бизнес только на этом создают (http://datacleaning.ru/).
Денис, все я понимаю. И если бы я проектировал такую бд с нуля, именно так и сделал.
Говорю же и исходная схема, вполне подойдет для тех задач, которые она выполняет. Но мне она все-таки не нравится.
Что конкретно? - это волюнтаризм при выборе предмета при реализации формы в вода данных за экзамен (хотя исходная схема и предусматривает наличие поля группа и в отношении студент и в отношении предмет)
А вообще наверное тему имеет смысл закрыть, или переформулировать в более широком смысле, как большинству и видится. А именно "Проектирование базы данных для регистрации результатов сессии в вузе" ?
Прикладываю заодно Образец Экзаменнационной ведомости
-
Учитывая пожелания общественности и используя в качестве исходного материала Экзаменнационную ведомость в предыдущем посте, предлагается новое видение задачи:
Ведомость имеет номер семестра (первый или второй) в течение учебного года XX-YY.
По факультету для курса и группы
По дисциплине
с формой отчетности - возможные варианты:
1. зачет - экзамен
2. просто зачет (отметка "зачтено" или "незачтено", баллы складываются из рейтинга за семестр до 50 баллов + баллы на зачете - еще 50 баллов, проходной бал по рейтингу 26, по итоговому зачету 52)
3. дифференцированный зачет с оценкой (выставляется оценка неуд, уд, хор, отл, не зачтено)
4. экзамен (рейтинг за семестр + баллы за экзамен с оценкой)
фио преподавателя на зачете или экзамене или на обоих вместе
Статистика зачета (итогового только) или экзамена
Число на экзамене
отличники
хорошисты
троечники
двоечники
неявившиеся (допущенные, но не явились, или не допущенные)
недопущенные (у кого меньше 26 баллов в семестре)
-
1. Один предмет могу вести несколько преподователей, но один преподователь для группы.
2. Не совсем понял, но мгне кажется, что все в строке ведомости должна быть одна строка - оценка, а тип оценки определяет "Форма отчетности"
3. А зачем Факультет связан с ведомостью?
4. Каким образом узнать какие сейчас предметы идут у данной группы?
5. ИМХО, надо добавить специальность (кафедру) и тогда будет куда препода привязать.
-
1. Один предмет могу вести несколько преподователей, но один преподователь для группы.
2. Не совсем понял, но мгне кажется, что все в строке ведомости должна быть одна строка - оценка, а тип оценки определяет "Форма отчетности"
3. А зачем Факультет связан с ведомостью?
4. Каким образом узнать какие сейчас предметы идут у данной группы?
5. ИМХО, надо добавить специальность (кафедру) и тогда будет куда препода привязать.
1.Да конечно, но не совсем. Обрати внимание на саму экзаменнационную ведомость, постом ниже. Сам документ. В ведомости отражается и зачет и экзамен.
Бывают ситуации когда на экзамене не менее 2 преподавателей, и на зачете тоже. А если группа большая, то преподавателей тоже может быть довольно много
2. Оценка формируется из составляющих, эти составляющие тоже важны. Либо надо вести рейтинг в другом месте, либо делать атрибутом строки. При этом обрати внимание на разные комбинации зачет - экзамен. По-моему проще все-таки сделать строку. Однако это пока концептуальная модель, а не реальная БД
3. Да конечно группа связана с факультетом, но и ведомость формируется деканатом определеного факультета, возможно эта связь и не нужна в данном контексте, она выводится из связи группы с факультетом
4.Безусловно - этого я пока не отразил. Вероятно надо создавать сущность учебный план, который связывается со специальностью или специализацией. Здесь возможно ситуация, когда одинаковая по номеру группа, но разного года приема может иметь несколько различные учебные планы и соотвественно некоторый иной набор дисциплин на экзамены
5. Это возможно - но для формирование ведомости это не так важно, однако если смотреть на ситуацию шире, то конечно. Однако думаю у тебя есть ведь недостаток информации, ты имеешь только один вид документа, и то в одном экземпляре. Для более широкого понимания нужна другая репрезентативная выборка. Пока контекст такой - сформировать модель отражающая исходный документ....
-
Тему конечно можно развить до логического конца, хотя в чем он. Расширение предметной области - вызывает и расширение объектов, связей, понятий и соотвественно саму сложность решения.
Все-таки давайте не слишком выходить за рамки предложенной задачи.
1. Документ Экзаменнационная ведомость - думаю достаточна для общего понимания
2. Что можно дополнить: скажем так разработать базу данных и приложение для ввода, редактирования, удаления данных о сессии.
3. Система должна позволять вводить результаты сессии и формировать различные статистические отчеты по успеваемости: по группе, по кафедре, по факультету, по вузу в целом. Выделять наиболее ярких студентов (ранжировать по сумме баллов по итогам всей сессии)
Источники информации: повторюсь Экзаменнационная ведомость
Положение о рейтинговой системе:
Оценка по дисциплине складывается из рейтинга за семестр (50) баллов и за экзамен или зачет (+50) баллов. Могут быть исключения когда разбалловка имеет другое соотношение, однако общая оценка равна 100 баллов за вид учебной деятельности: аудиторные занятия по дисциплине, курсовая работа, квалификационная работа(бакалавр, инженер, магистр), учебные и технологически практики.
Зачетной оценкой считается оценка не менее 52 баллов. При этом за семестр должно быть не менее 26 баллов и за зачетное мероприятие еще 26 баллов. Опять же могут быть исключения в случае особых видов учебной практики.
52-69 удовлетворительно
70-84 хорошо
85-100 отлично
Ниже не удовлетворительно или не явился.
Для более качественно анализа дополним задачу некоторыми фактами
Студент поступает на некоторую специаьность. На одной и той же специальности может быть сформирована одна или несколько (обычно еще 1 группа) групп. При этом группы могут различаться специализацией.
Специальность (или специализация) прерогатива только одной кафедры. На кафедре может быть несколько специальностей.
Кафедры составляют факультет. Существуют выпускающие и общедисциплинарные кафедры. Общедисциплинарные кафедры обычно не имеют собственных специальностей, однако могут и иметь. Например кафедра Информатики и вычислительной техники выпускает специалистов 230201 и одновременно ведет общие дисциплины для всех потоков вуза.
На зачете и экзамене могут быть несколько преподавателей. Случай когда один предмет ведется двуми и более преподавателями-лекторами, группа разбивается на подгруппы (2 редко 3) каждая, из которых имеет своего преподавателя выставляющего зачет. Однако возможен и один преподаватель(практические занятия без деления на подгруппы)
Некоторые пожелания для аналитиков, которые заинтересуются проектом. Моделирование можно вести в объектной парадигме(возможно только в ней). При выполнении анализа предложить важные этапы его, с возможностью объяснения причин почему это имеет смысл делать. Пытаться не выходить за рамки постановки задачи. Если требуется выйти показать почему это необходимо делать, какие прблемы возникают если этого не делать.
Модераторам ветки просьба перенести тему в раздел обучение!
Форумчанам: предлагаю сформировать ряд таких небольших проектов, в которых показательно выявить типичные ошибки в постановке задачи, пути преодоления неясно сформулированной задачи, принципы и этапы анализа задачи и выработки решения вплоть до реализации.
Для быстрого прототипирования предлагаю использовать MDA технологию и в частности BOLD for Delphi 7 или ECOIII
Прошу прощения за ошибки и опечатки - надеюсь, наказывать сильно за это не будете :-)