Database Security Issues for Real-Time Electronic Commerce Systems
Sang H.Son
Dept.of Computer Science
University of Virginia
Charlottesville,VA22903,USA
son@https://www.doczj.com/doc/4414503133.html,
Abstract
Data management and transaction processing are essential in supporting advanced time-critical appli-cations.In many of these applications,security is another important requirement.Security is espe-cially critical in electronic commerce applications where databases often maintain and provide sensi-tive information.In electronic commerce,service providers are sensitive to the needs of the clients, including the implicit(or explicit)timing con-straints.If providing full security to each activity causes the system to become less timely,the service providers would be reluctant in providing necessary security guarantees.Therefore,it is important to consider multiple security service levels for applica-tions such as electronic commerce.In this paper we address issues that the system designers should con-sider for supporting both requirements of timeliness and security.We discuss the issues for transaction and data modeling,and present the notion of partial security.We also discuss a speci?cation language that allows the designer to specify important proper-ties of the database at an appropriate level to sup-port partial security.
1.Introduction
A real-time system is one whose basic speci?cation and design correctness arguments must include its ability to meet its timing constraints. This implies that its correctness depends not only on the logical correctness,but also on the timeliness of its actions[Shin94].To function correctly,it must produce a correct result within a speci?ed time, called deadline.In these systems,an action per-formed too late(or even too early)may be useless or
This work was supported in part by National Security Agency grant MDA904-96-1-0096,and by Of?ce of Naval Research.even harmful,even if it is functionally correct. Although it is commonly believed that meeting the timing requirements is a matter of increasing system throughput suf?ciently,research in real-time sys-tems has discredited this notion.
As real-time systems continue to evolve,their applications become more complex,and often require timely access to(and predictable processing of)massive amounts of data.This need for advanced data management functionalities in real-time systems poses intellectual and engineering challenges that must be tackled to allow for practical solutions to the problems faced in development of real-time database systems.The importance of real-time database systems in an increasing number of applications,such as aerospace and defense sys-tems,industrial automation,business information systems,traf?c control,and telecommunication has resulted in an increased research effort in this area [RTDB96,RTDB97].In many of these applica-tions,security is another important requirement, since the system maintains sensitive information to be shared by multiple users with different levels of security clearance.As more and more of such sys-tems are in use,one cannot avoid the need for integrating them.That is,real-time systems have to be made acceptably secure and the secure systems need to support the timeliness requirements of real-time applications.
Recently,electronic commerce becomes an interesting application where both security and real-time requirements should be considered together.Electronic commerce is a general concept covering any form of business transaction or infor-mation exchange between organizations of various types,or between service providers and clients, using information and communications technology provided over the Internet.A database is a critical infrastructure that is essential in electronic com-merce to support complex and?exible services to
manage requests in the context of highly dynamic workload with diverged requirements[Ghosh98]. Security is critical in electronic commerce applica-tions where the system often manages sensitive information(such as credit card numbers and account passwords).Building blocks of such an application should ensure security and timeliness to provide mechanisms for searching,negotiating,ord-ering,billing,payment,distribution,contracting, and other client-speci?c services.
In electronic commerce,service providers are usually very sensitive to the needs of the clients, including the implicit(or explicit)timing con-straints.If providing full security to each activity causes the system to become less timely,service providers would be reluctant in providing necessary security guarantees.If the amount of money at stake is below certain threshold(e.g.,less than$10),the system should use mechanisms with less overhead for timely service,although it may involve certain level of risk(e.g.,loss of$10due to incomplete credit check).
Traditionally,the notion of security has been considered binary[Ting95].A system is either secure or not.A security hole either exists or not. The problem with such binary notion of security is that in many cases,it is necessary to develop a sys-tem that provides an acceptable level of security and risks,based on the notion of partial security rather than unconditional absolute security,to satisfy other con?icting requirements such as real-time perfor-mance.In that regard,it is important to consider multiple security service levels for applications such as electronic commerce.To achieve that,we need to de?ne the meaning of partial security,for security violations of sensitive data must be strictly con-trolled,while the cost of providing that level of ser-vice should not reduce the timeliness of the system.
To improve the timeliness in secure and time-critical applications such as electronic commerce, several issues need to be carefully considered.The research in this area has been focused on identifying architectural and transaction processing issues [Geo97,Muk97,Park97,Son93,Son95,Son97, Son98].It was suggested that a more rigorous model to capture the characteristics and semantics of transactions and data is necessary.This will enable ef?cient processing to improve the timeliness of the system.In addition,new approaches to supporting both requirements in transaction scheduling and concurrency control that can make trade-offs if necessary,need to be developed and analyzed.
Security is concerned with the ability of a sys-tem to enforce a certain policy governing the use, modi?cation,and destruction of information.There are two different policies that have been studied: discretionary security policy and mandatory(or multilevel)security policy.Discretionary security policies de?ne access restrictions based on the iden-tity of users,the type of access,and objects being accessed.While discretionary access control has been used in several systems,it may not be adequate for preventing unauthorized disclosure of the infor-mation[Woo83].The most well-known model for multilevel security is the Bell-LaPadula model [Bell76].In the Bell-LaPadula model,security poli-cies are stated in terms of subjects and objects.A subject is an active entity that can access objects. Every object is assigned a classi?cation,and every subject a clearance.Classi?cations and clearances are collectively referred to as security classes(or levels)and they are partially ordered.The Bell-LaPadula model imposes the following restrictions on all data accesses:
(1)Simple Security Property:A subject is allowed
read access to an object only if the former’s
clearance is identical to or higher(in the par-
tial order)than the latter’s classi?cation. (2)The*-Property:A subject is allowed write
access to an object only if the former’s clear-
ance is identical to or lower than the latter’s
classi?cation.
Database systems that support the Bell-LaPadula properties are called multilevel secure database systems.The Bell-LaPadula model prevents direct?ow of information from a higher access class to a lower access class,but the condi-tions are not suf?cient to ensure that security is not violated indirectly through what is known as covert channels[Lamp73].A covert channel allows indirect transfer of information from a subject at a higher access class to a subject at a lower access class.An important class of covert channels that are usually associated with concurrency control mechanisms are timing channels.A timing channel arises when a resource or object in the database is shared between subjects with different access classes.One way to eliminate covert channels is to
design a system that meets the requirements of non-interference[Gog84].
From our earlier study,it became clear that security requirements are not compatible with real-time requirements[Son93,Son95].Frequently, priority inversion is necessary to avoid covert chan-nels.Consider a transaction with a high security level and a high priority entering the database,and it ?nds that a transaction with a lower security level and a lower priority holds a write lock on a data item that it needs to access.If the system preempts the lower priority transaction to allow the higher priority transaction to execute,the principle of non-interference is violated,for the presence of a high security transaction affects the execution of a lower security transaction.On the other hand,if the system delays the high priority transaction,a priority inver-sion occurs.The system has encountered an unresolvable con?ict.
In general,these unresolvable con?icts occur when two transactions contend for the same resource,with one transaction having both a higher security level and a higher priority level than the other.Therefore,creating a database that is com-pletely secure and strictly meets real-time require-ments is not feasible.A system that wishes to accomplish the fusion of multi-level security and real-time requirements must make some concessions at times.An important but challenging problem to be addressed in supporting security and real-time is identifying the correct metrics to evaluate the level of security obtained in an adaptable system.
In this paper,we discuss issues for transaction and data modeling,and present the notion of partial security.We also discuss requirement speci?cation that allows the designer to specify important proper-ties of the database at an appropriate level to support that notion.Major concerns are the impact on sys-tem timeliness associated with the introduction of security requirements.
The rest of the paper is organized as the fol-lowing.In the next section,we present an approach to developing a model for secure real-time data objects and transactions.Section3discusses the notion of partial security and Section4presents a speci?cation language to specify requirements and the rules to resolve con?icts at run-time.Section5 concludes the paper with the planned future work.2.A Model for Data and Transactions
Transaction processing in database systems for electronic commerce may require different data models and correctness criteria to support security and timeliness.Most real-time database scheduling algorithms have been developed and evaluated under almost the same workload and operating environment model as used in conventional database systems.While this model is suited to some real-time database applications,in electronic commerce where real-time and security requirements need to be satis?ed,different characteristics and semantics of their data and transactions should be utilized.
Databases used in electronic commerce store transactions and data that might need to be updated when transaction occur.Several different types of transactions may need to be executed on the data-bases.For example,in stock trading application,the database should keep track of several hundreds of thousands of?nancial instruments world-wide.The stream of update requests can be up to500 updates/second during peek time[Coch94].Many of them could be periodic while some others could be triggered to compute indices or other composite values on request.At the same time,clients of the system may submit transactions to check the price and perform trading on speci?c stocks.Some of the timing constraints associated with them could be critical,while others can be soft.Some of the data may be accessible to all the clients,while access to certain sensitive information is restricted only to privileged members.To achieve such restrictions, different portions of the database may have different access control policies based on the user status. Various security-assurance techniques can be used, ranging from user authentication using encrypted passwords for the database to encrypted storage of highly sensitive data in the database.
We have developed a model for data and tran-sactions for both soft and critical real-time systems [Kim96].The model provides a strong basis not only for performance study of real-time transactions but also characteristics and requirements of real-time database systems to support different classes of transactions.In that model,a real-time database consists of a set of data objects representing the state of an external world.There are two types of data objects in a real-time database system:continuous and discrete.
Continuous data objects are related with exter-nal objects continuously changing with time.The value of a continuous data object can be obtained directly from external world(image object)or com-puted from the values of a set of image data objects (derived object)with a regular interval.Discrete data objects are static in the sense that their values do not depend on the value of any continuous data object.In other words,the values of discrete data objects do not become obsolete as time passes,but are valid until update transactions actually change the values.
Based on the nature of transactions in real-time database systems,they can be characterized by the following attributes:implication of missing speci?ed timing constraints,arrival pattern,data access pattern,data requirement,resource require-ment,and data types to be accessed.Considering those characteristics of real-time data and transac-tions,there are hundreds of possible transaction classes.However,some of them are infeasible and others can be grouped together to be processed dif-ferently.Most real-time database researchers use a model that includes only a subset of the above classes and never discriminate transactions in the system.However,in practice,all kinds of transac-tions can coexist in one system.The performance goal of such a real-time database system is?rst to guarantee all critical timing constraints of transac-tions,to achieve the performance requirements of transactions given by the form of timeliness,and ?nally to minimize the deadline miss ratio(or max-imize the total values)of soft real-time transactions. To achieve this performance goal,it is necessary to apply different transaction scheduling and con-currency control algorithms to each type of transac-tions.
An important question to ask is what are the implications of introducing security requirements into the model.Three categories of data(image, derived,and discrete)should be further classi?ed according to their security levels.This will lead to more complex methods in satisfying the consistency and timeliness requirements,while meeting the security requirements.In fact,the database may not be able to satisfy all three requirements during cer-tain intervals of time,when different processing schemes are used for each type of transactions.It is because that a certain type of transactions need to be executed separately from transactions of other types to satisfy timeliness,even though the security and consistency requirements indicate that there is a cer-tain relationship among those transactions to be maintained.In our model,a typical real-time data-base application consists of the following classes of transactions:
Class I Transactions:This class includes periodic transactions with critical deadlines.All the data and run-time requirements are supposed to be available for Class I transactions in advance.Since Class I transactions write only into continuous data objects that require only temporal consistency,it is feasible to guarantee their critical timing constraints under an appropriate scheduling algorithm.
Class II Transactions:Transactions of this class have critical timing constraints which come from their response-time requirements,unlike the timing constraints of Class I transactions which come from the attributes of data.However,they are not neces-sarily periodic and a priori knowledge of their resource requirements is not completely available. Also,they may access discrete data objects which require serializable accesses.For this reason,we cannot always guarantee that a Class II transaction will meet its deadline.This is the transaction class in which each transaction can have a different guarantee level as its performance requirement. Class III Transactions:All real-time transactions not belonging to any of the above classes are categorized in this group.They have either soft or ?rm deadlines,their data and run-time requirements are not always known,and they can access both con-tinuous and discrete data objects.Class III transac-tions can be further divided into several classes and processed differently.For example,a priori knowledge of the attributes of a transaction is some-times available for some soft real-time transactions and should be utilized to improve the system perfor-mance.Much work has been already done for Class III transactions[Abbo92,Lam97,Lee96].
To support security and timeliness require-ments in database systems for electronic commerce, it will be useful to classify different types of transac-tions based on their security requirements,and develop processing schemes for each type of tran-sactions.A model should include security features as outlined in the following:
(1)Different from data objects in traditional data-
bases,continuous data objects that represent
the state of the external world should have
additional attributes such as timestamp(the
time at which the value was introduced),tem-
poral validity duration(during which the value
is believed to be valid),and security level.A
continuous secure data object is in a correct
state if and only if the value of the object
satis?es the temporal validity requirement and
it is maintained according to the non-
interference rule.Both continuous and
discrete secure objects must be accessed fol-
lowing the access control policies speci?ed. (2)A transaction should have the additional attri-
butes such as arrival time,deadline,periodi-
city,criticality,execution time estimate,
resource requirements,and security level.
According to the values of these attributes,
transactions can be categorized into hierarchy
of classes.
Transactions can be grouped according to the classi?cation scheme as discussed above:
Class I:Critical and periodic transactions.
Class II:Critical and aperiodic transactions.
Class III:Non-critical transactions.
Each class can be further categorized according to their security levels.For example,there will be Class I.1(top secret Class I),Class I.2(secret Class I),Class I.3(con?dential Class I),and so https://www.doczj.com/doc/4414503133.html,-patibility among different accesses to secure data objects by transactions from different classes need to be carefully designed to be used for specifying the correctness of multilevel secure transaction pro-cessing.If a database utilizes the characteristics of data and transactions as discussed above,it can make decisions to further improve the system per-formance in meeting the security and timeliness requirements.It can also consider necessary trade-offs to be made in case both requirements cannot be met at the same time.
3.Partial Security
To achieve the desired level of timeliness,the system may need to allow potential security viola-tions at times.When the system has to trade-off security,the system is no longer completely secure; rather it only will be partially secure.In that case,it is extremely important to de?ne the exact meaning of partial security.In fact,several security practi-tioners recognize that complete security is a fallacy ---there is no system completely secure.In one way or the other,any operational system becomes vulnerable to security leaks.The real question is how we can make the system acceptably secure while it remains available and provides timely ser-vices.With appropriate policies and the mechan-isms to enforce them in the system,we provide the increased availability and timeliness in situations where other systems without such capability may just freeze or stop operating to ensure the(ima-ginary)complete security.Two of the major research issues to be addressed are1)to identify pol-icies to specify quantitative levels of partial security, and2)mechanisms to enforce the required level of partial security.
One approach could be to de?ne security in terms of a percentage of potential security violations allowed in the system.However,this approach is not useful because it is a bad metric.Even though a system may allow a very low percentage of security violations,this fact alone reveals nothing about the security of individual data.For example,a system might achieve99%security level,but that1%of insecurity might allow the most sensitive piece of data to leak out.For serious security applications,a more precise metric is necessary.
A better approach involves adapting the Bell-LaPadula security model and de?ning security requirements such that partial security could be allowed only between certain security levels.In this way,the designer can specify that the most sensitive information will never be allowed to be involved in potential security violations.Initially,the system may support the original Bell-LaPadula security model.As the real-time performance of the system degrades,the system allows more potential security violations and reduces the number of security con?https://www.doczj.com/doc/4414503133.html,ing this scheme,we can still make guarantees about the security of the data,based on the speci?cation of the security policy.
For example,consider a system with four security levels:top secret,secret,con?dential,and unclassi?ed.Partial security policies can be speci?ed by the level of security guarantees pro-vided,from fully secure to completely insecure.For
instance,level-4security indicates full security, regardless of the real-time performance of the sys-tem.As guarantee levels are lowered,potential security violations are allowed between certain lev-els.For a level-3security guarantee,transactions that are at the unclassi?ed level may have con?icts with transactions at the con?dential level in access-ing unclassi?ed data,resulting in a potential covert channel.In a sense,this represents a system with only three security levels:top secret,secret,and unclassi?ed.However,it does not mean that there is no distinction between con?dential and unclassi?ed levels.Transactions that are at the unclassi?ed level cannot directly access con?dential data.
It is possible to combine this approach with other methods of specifying the degree of potential security violations.For example,we can use the bandwidth of the covert channels that may show up as the result of the security violation,or use the fre-quency of such violations in terms of the percen-tages to de?ne partial security.In this way,the amount of security violations between two levels for which partial security is allowed would be required to fall below the speci?ed bandwidth or frequency. Note that guarantees can still be made between lev-els designated as allowing no security violations;for the other levels,database designers can use different bandwidth/frequency to denote their preferences on where and how much they would rather have the potential security violations occur.
To be useful in real applications,different par-tial security policies need to be identi?ed so that the policy makers can decide which one is acceptable, considering potential violations and their conse-quences.In many cases,it would be helpful if par-tial security policies are in a strict partial order in terms of satisfying the timeliness and security requirements.
Detection of potential security violations is a key requirement to support any partial security poli-cies.Whenever two activities(e.g.,transactions)at different security levels share a resource,there is a potential for security violation.At the data object level,such detection can be done by the transaction scheduler and data manager.It is possible that there are other potential security violations in the system that cannot be systematically detected.However, without proper detection mechanisms,there is noth-ing much we can do about it.The security policies discussed in this paper deals with potential violations that can be detected.
4.Speci?cation of Requirements
Application designers should be able to specify semantic information using a speci?cation language to express the relative importance of keep-ing the desired level of security and meeting the timeliness requirement.A question to be addressed in that approach is the veri?cation of the given speci?cation.Speci?cations should be compiled and veri?ed to check any inconsistency in the require-ments and to clearly determine the necessary actions to be taken.In this section,we present a simple speci?cation language that could be used to allow the designer to specify the database semantics and real-time/security requirements.The language should be able to support the designer in specifying rules which could be referred at run-time to resolve the con?icts.
Once the speci?cation is given,it needs to be analyzed to identify any inconsistency and to gen-erate rules based on the semantic information on data and transactions to be used at run-time.One approach to specifying the security and real-time requirements is a tool that aids the designer?rst with locating con?icts and then with denoting their preferences according to the semantics of the data-base.
4.1.Speci?cation Language
The speci?cation language should allow designers to create rules at varying levels of detail. In applications where much information is known about the database beforehand,designers can control security and real-time aspects of the database much more tightly than in situations where less is known beforehand or such a tight control is not required. There should be multiple levels of detail in the speci?cation scheme.If appropriate,the designer should be able to use all the levels to specify the requirements.There are three levels of detail in our speci?cation scheme.
In the speci?cation language we are develop-ing,the speci?cation consists of two parts:a description of the database and a set of rules to fol-low when con?icts arise.The description provides a framework for the rules.The speci?cation of both the description and the rules varies between the dif-ferent levels of details.Regardless of the levels of
details that are used,the?rst part of the speci?cation contains facts about the database as a whole.Here, the designer speci?es the number of data items,the number of security levels,and the number of prior-ity levels used in the entire database.It also allows to specify any detail information regarding transac-tions that can be invoked.
Information about transactions and data should be speci?ed.Transactions are given a number of components.Each transaction is given a readset and a writeset.These can consist of any number of data items.If no readset or writeset is given,they are assumed to be empty.The real-time requirements of a transaction are given by four variables:priority, execution time,release time,and periodicity.The periodicity of a transaction de?nes how often it starts executing,and the release time indicates the offset of the periodic start.Finally,transactions are given a security level.
Data items are speci?ed by number,and each data item is given a security level.The speci?cation can also contain a default security level,which is assigned to any unspeci?ed data items.All of the information about transactions and data belong to the description portion of the speci?cation.Not all of these components for transactions and data are required.In general purpose database systems,some of the information might be hard to specify.How-ever,in many real-time applications,most informa-tion is available,since such information is necessary for schedulability analysis of the system to support the timeliness and predictability requirements.In fact,in real-time database systems,many transac-tions are periodic and their access pattern is known. The only truly necessary components are the secu-rity level and the priority level.If a designer leaves out,for example,the readset or the writeset,the speci?cation processing tool cannot make any assumptions about the data accessed by this transac-tion,so it must assume that the transaction may con?ict with every other transaction.
The second part of the speci?cation presents a set of rules at varying levels of detail.The rules de?ne the system behavior when con?icts occur. These rules can either be static or dynamic.Static rules apply to con?icts that are resolved in the same way every time.For example,the user might specify that a con?ict between two speci?c transactions,or two categories of transactions,will never result in a security violation.Dynamic rules can depend on certain run-time variables that the database keeps track of during execution.In our scheme,dynamic rules can be based on three different system vari-ables:security violation percentage,transaction miss percentage(the percentage of transactions that have missed their deadlines),and the number of consecu-tive missed deadlines.Each dynamic rule has a list of clauses and a default action.A clause contains a Boolean comparator(>,>=,=,<,or<=)between these three system variables and a constant value. Each clause contains an action to be taken if the Boolean comparison is true.
When a con?ict is encountered by the database system,it checks the?rst clause.If that clause is true,it takes the associated action.If not,it checks the next clause,and so on.Therefore,the designer should be careful in determining the evaluation order of the rules.If none of the clauses turns out to be true,the database takes the default action.For example,a rule might be"If the security violation percentage is greater than5,violate security.Other-wise violate timeliness."Here,the"otherwise"sen-tence represents the default action.
In the?rst,most detailed level,the designer can generate rules for speci?c transactions.The second level of speci?cation detail replaces speci?c transactions with categories of transactions.Tran-sactions are categorized by their security levels and priority levels.The designer can create any number of categories at any granularity that he or she feels is appropriate,and describes these categorizations in the description portion of the speci?cation.Then, rules are created for con?icts between categories of transactions.These rules are the same as the rules for the?rst level.
In the third level of speci?cation,designers create a set of rules describing actions to be taken in case of con?icts that are not speci?ed in the lower levels.This can be considered as the general system policy.Conditions would depend on the charac-teristics of the transactions that are con?icting or the current performance statistics.Depending on the results of the comparison,the rule would mandate either a security violation or a priority violation.All of this information belongs in the rules portion of the speci?cation;nothing is needed in the descrip-tion portion.By carefully creating the rules,the database designer can implement the partial security policy suitable for the application.
Speci?cations are not required to solely use one of these levels of details.The descriptions and rules for these detail levels can be mixed.In this case,when the database encounters a con?ict during execution,it ?rst searches to see if a level 1rule applies.If not,it searches the level 2rules,and ?nally checks the level 3rules.As with other aspects of specifying the requirements,a tool can help the designer to model their partial security sys-tem.
4.2.An Example
Figure 1shows an example of a system com-pletely speci?ed with detail level 1.This example presents a database with 100,000data objects that could have 5security levels and 10priority levels.This is a small example,with only two transactions.Every relevant component of these transactions has
________________________________________________________________________________________Description:
numDataItems 100000;numSecurityLevels 5;numPriorityLevels 10;data[default].security =1;data[3].security =2;
ComputePro?t.readset =1,2,3,4;ComputePro?t.writeset =5;ComputePro?t.periodicity =12;ComputePro?t.priority =3;ComputePro?t.security =3;
UpdatePrice.writeset =3;#Two transactions access data item 3.UpdatePrice.periodicity =30;UpdatePrice.security =2;UpdatePrice.priority =2;
Rule for ComputePro?t-UpdatePrice con?ict:(SecViolation%>=5)~violateTimeliness,(TransMiss%>10)~violateSecurity,(otherwise)~violateTimeliness;
Fig.1.An example of speci?cation with fully speci?ed detail level 1
________________________________________________________________________________________
been speci?ed.Both transactions access data item 3,and UpdatePrice writes to it,so we have a potential con?ict.Since UpdatePrice has both a lower security level and a lower priority level than ComputePro?t,this con?ict cannot be resolved without causing either a covert channel or a priority inversion.Had UpdatePrice been given a higher priority than ComputePro?t,we can satisfy both requirements by allowing UpdatePrice to preempt ComputePro?t.Alternatively,if UpdatePrice had a higher security level than ComputePro?t,then both requirements could be satis?ed by forcing UpdatePrice to wait for ComputePro?t transaction.The task of locating such con?icts can be automated.
In the rule speci?cation,SecViolation%indi-cates the percentage of security violations and TransMiss%indicates the percentage of deadline miss ratio.Each rules consists of a condition and a
decision.The condition part of a rule is stated inside the parenthesis and followed by the decision after tilde(~).Conditions can be connected by logical AND(&)of OR(|).In the rule,the?rst line represents a security crisis.If more than5percent of transactions have violated security,then this transac-tion cannot afford to,so it must violate timeliness.If the condition in the?rst line is false,the condition in the next line is checked.This line represents a real-time crisis.If more than10percent of transac-tions have missed their deadlines,then the real-time performance is suffering,so this transaction must violate security.Again,if the condition in this second line is false,the next line is checked.Here, this line is the"catch-all"rule.If none of the above rules apply,the database is instructed to violate timeliness.
5.Conclusions
In this paper,we have addressed some issues that the designer of database systems for real-time electronic commerce should consider for supporting both requirements of timeliness and security,and presented the notion of partial security as one approach.There are a number of issues that need to be looked into.First of all,a proper characterization of the capacity of a covert channel that can arise given a particular value of potential security viola-tion needs to be derived.Applications might express a desired level of security in terms of a maximum admissible capacity of a potential covert channel. Unless there is a way of determining to what extent a security policy satis?es the security properties,one cannot determine whether the policy is suitable for the application.An adaptive trade-offs could be made between several factors,such as the deadline miss ratio(or tardiness of the system)and the differ-ence between required security level and the level actually being served.Considering different opera-tion mode,based on the workload,could be another interesting issue.For example,it would be valuable to check how a policy to screen out transactions that are about to miss their deadlines would affect the performance.
We have introduced the concept of partial security and presented a speci?cation language to express rules to be used at run-time to resolve con?icting requirements.The language and the veri?cation tool need to be re?ned to provide the functionality of checking the completeness and consistency among the rules at different levels. Also in this paper,we have not fully developed a model for secure real-time transactions and data,and how to detect the potential incompatible con?icts between real-time requirements and security requirements.We plan to work on those issues.
References
[Abbo92]Abbott,R.and H.Garcia-Molina, "Scheduling Real-Time Transactions:A
Performance Evaluation",ACM Trans.
on Database Systems,vol.17,no.3,
Sept.1992.
[Bell76]Bell,D.E.and https://www.doczj.com/doc/4414503133.html,Padula,"Secure Computer Systems:Uni?ed Exposition
and Multics Interpretation",Tech.
Report,The Mitre Corp.,March1976. [Coch94]Cochinwala,M.and J.Bradley,"A Mul-tidatabase System for Tracking and
Retrieval of Financial Data,"VLDB
Conference,1994,pp714-721.
[Geo97]George,B.and J.Haritsa,"Secure Tran-saction Processing in Firm Real-Time
Database Systems,"ACM SIGMOD
Conference,Tucson,AZ,May1997. [Ghosh98]A.Ghosh,E-Commerce Security:Weak Links,Best Defenses,Wiley Computer
Publishing,John Wiley&Sons,Inc.,
New York.
[Gog84]J.Goguen and J.Meseguer,"Unwinding and Inference Control,"IEEE Symposium
on Security and Privacy,Oakland,CA,
April1984,pp75-86.
[Kim96]Kim,Y.and S.H.Son,"Supporting Predictability in Real-Time Database
Systems,"IEEE Real-Time Technology
and Applications Symposium(RTAS’96),
Boston,MA,June1996,pp38-48. [Lam97]https://www.doczj.com/doc/4414503133.html,m,S.Hung,and S.H.Son,"On Using Real-Time Static Locking Proto-
cols for Distributed Real-Time Data-
bases,"Journal of Real-Time Systems,
vol.13,no.2,pp141-166,Sept.1997. [Lamp73]Lampson, B.W.,"A Note on the Con?nement Problem,"Communications
of the ACM,16(10),pp613-615,October
1973.
[Lee96]Lee,J.and S.H.Son,"Concurrency Control Algorithms for Real-Time Data-
base Systems,"Performance of Con-
currency Control Mechanisms in Cen-
tralized Database Systems,V.Kumar
(ed.),Prentice Hall,1996.
[Muk97]R.Mukkamala and S.H.Son,"A Secure Concurrency Control Protocol for Real-
Time Databases,"Database Security:
Status and Prospects, D.Spooner,S.
Demurjian,and J.Dobson(eds.),Chap-
man and Hall Publishing,pp215-230,
1996.
[Park97] C.Park,S.Park,and S.H.Son, "Priority-driven Secure Multiversion
Locking Protocol for Real-Time Secure
Database Systems,"Annual IFIP WG
11.3Conference of Database Security,
Lake Tahoe,CA,Aug.1997,pp200-211. [RTAS97]IEEE Symposium on Real-Time Tech-nology and Applications,Montreal,
Canada,June1997.
[RTDB96]International Workshop on Real-Time Databases,Newport Beach,CA,March
1996.
[RTDB97]International Workshop on Real-Time Databases,Burlington,Vermont,Sept.
1997.
[RTSS97]IEEE Real-Time Systems Symposium, San Francisco,CA,Dec.1997.
[Shin94]Shin,K.G.and P.Ramanathan,"Real-Time Computing:A New Discipline of
Computer Science and Engineering,"
Proceedings of IEEE,Special Issue on
Real-Time Systems,vol.82,no.1,Janu-
ary1994.
[Son93]Son,S.H.and B.Thuraisingham, "Towards a Multilevel Secure Database
Management System for Real-Time
Applications,"IEEE Workshop on Real-
Time Applications,New York,New
York,May1993.
[Son95]S.H.Son,R.David,and R.Mukkamala, "Supporting Security Requirements in
Multilevel Real-Time Databases,"IEEE
Symposium on Security and Privacy,
Oakland,CA,May1995,pp199-210. [Son97]S.H.Son,R.David,and C.Chaney, "Design and Analysis of an Adaptive
Policy for Secure Real-Time Locking
Protocol,"Journal of Information Sci-
ences,vol.99,no.1-2,June1997,
pp.101-135.
[Son98]S.H.Son,C.Chaney,and N.Thomlin-son,"Partial Security Policies to Support
Timeliness in Secure Real-Time Data-
bases,"IEEE Symposium on Security and
Privacy,Oakland,CA,May1998,pp
136-147.
[Ting95]Ting,T.C.,"How Secure is Secure?"
Opening Remarks,IFIP WG11.3Work-
ing conference on Database Security,
Rensselaerville,New York,Aug.1995. [Woo83]Woods Hole Report,"Multilevel Data Management Security,"Committee on
Multilevel Data Management Security,
National Research Council,Washington,
DC,1983.
实验报告 实验名称:基于ER图的数据库设计与简单操作 班级: 姓名: 学号: 实验时间: 2010年5月18日 成绩:指导老师: 一、实验目的: (1能够正确运用数据库的基本理论和方法。 (2熟悉常用关系型数据库的设计和基本操作。 (3熟悉关系数据库规范化设计理论,能够设计并建立科学合理的数据库,正确建立数据库中表与表之间的关系。 (4进一步正确理解数据库设计思路,培养分析问题、解决问题的能力,提高查询资料和撰写书面文件的能力。 二、实验设备及主要内容 实验设备:“Microsoft SQL Server”——“企业管理器”和“查询分析器”主要内容: 1.高等院校学生补考管理业务需求描述。高等院校补考管理系统应具备编辑补考学生信息、安排补考时间地点等基本管理功能,具体要求如下:
3对教室的编号、地点和容纳人数进行编辑。 4自动安排补考的时间、地点(即教室。 5录入学生的补考成绩。 6分别按照院系、专业、班级等查询参加补考的学生信息。 7按照补考的时间和地点查询参加补考的学生信息。 8查询和打印补考时间、地点的安排。 9查询和打印补考不及格学生的信息。 2.设计数据库。根据上述业务描述,设计数据库总体方案,明确数据库中表的结构,各表中关键字的设置,表与表之间的关系。 3.根据功能需求,以SQL语句的形式分类列出系统应涉及的数据操作。 4.利用Access、VFP或SQL server建立数据库,并成功实现基本数据操作。 5.提交书面实验报告。 三、实验步骤 步骤一:按照上述要求进行数据库和表的设计。具体包括:领域描述、概念模型用E-R图描述、从E-R图导出关系数据模型。 步骤二:选择Access、VFP或SQL server实现数据库操作。
安全监测管理数据平台 第一部分系统简介 一、系统介绍 远程监控系统组态平台可将数据、图像、声音共一个平台集中监控，C/S+B/S 结构，可同时采用RS485技术及LONWORKS技术等多种技术，该组态平台软件可用于机房集中监控、变电站远程监控、楼宇控制、动力环境集中监控、安全防范监控、智能小区监控管理、智能大厦监控管理、工业控制、远程数据图像声音监控，已在海关、电力、保险、银行、政府机关、工厂、电信及移动等各行业大量使用。 整个监控系统均为模块化结构，组建十分灵活，扩展十分方便。可实现机房设备运行管理的无人值守，极大的提高了资源利用率和设备运行管理水平。二、系统主要特点 ◆系统采用分布集中监控方式，适合多层多级部门建立分布集中管理模式。 ◆报警方式包括屏幕报警、电话语音报警、modem语音报警、短信息及电子邮件. ◆强大的报警处理功能。可区分多级的报警级别，报警事件发生时系统自动按事件级别排 队报警，显示，处理，并将画面切换报警画面。 ◆系统支持各式各样的UPS、空调、电量仪、门禁、消防监控主机等设备直接监控，对新 设备新通讯协议的监控不需编程。 ◆界面：令操作人员一目了然。参数实时动态显示，界面完全汉化，场地布局，设备照片 或图片直接显示屏幕上，场景逼真，鼠标控制，操作简单。
第二部分服务器操作说明 一、启动运行服务端 A、运行“安装目录：\“:集中监控系统\服务端”目录下的“SERVER.EXE”. B、“开始”-》“程序”-》“集中监控系统”-》“监控服务器”。 C、桌面上点击“集中监控系统服务端”。 以上三种方式均可运行监控系统服务端程序，运行后界面如下： 用户名：登录系统的用户名称。系统默认：admin。 密码：此用户的密码，系统默认为空密码。 二、系统菜单说明 1）日常操作 启动：启动数据采集。 停止：停止数据采集。 退出：退出本系统。 2）系统配置 时间调度设置报警时间段及拨打报警电话、发送报警短信及报警EMAIL的时间调度。
某某石油管理局企业标准 数据库系统安全开发和改造规范 某某石油管理局发布 前言 本标准由某某石油管理局计算机应用及信息专业标准化委员会提出并归口。 本标准由某某石油管理局信息中心起草。 本标准的主要内容包括： 适用范围、术语定义、数据库的开发和改造等几部分。 1范围 本标准规定了局某某石油管理局某某油田数据库系统安全开发与改造规范。 本标准适用于某某油田（企业内部）数据库系统安全开发与改造的全过程。 2规范解释权 某某油田信息中心网络标准和规范小组 3基本原则 本规范是参考国家相应标准，并参考相应国际标准，并结合某某油田的相应实际而制定 4使用说明 1)本规范所提到的重要数据应用部门，如无特别说明，均指某某油田范围内 各个有重要数据（如生产数据，管理数据等）的部门，这里不具体指明，各单位可以参照执行。 2)本规范说明了如何在现有数据库系统上应用的开发与改造方法，但不包括 数据系统的应用与管理。也不说明数据库系统本身的开发与改造方法。 5总则 1)为加强某某油田各单位数据库技术管理，有效地保护和利用数据库技术资 源，最大程度地防范技术风险，保护使用者的合法权益，根据《中华人民共和国计算机信息系统安全保护条例》及国家有关法律、法规和政策，结合油田的实际情况，制定本规范。 2)本规范所称的数据库，是指所有与油田业务相关的信息存储体的集合。
3)某某油田中从事数据库开发与改造的人员，均须遵守本规范。 6数据库系统的基本概念 数据、数据库、数据库管理系统和数据库系统是与数据库技术密切相关的四个基本概念。 数据是数据库中存储的基本对象。数据在大多数人的头脑中第一个反应就是数字。其实数字只是最简单的一种数据，是数据的一种传统和狭义的理解。广义的理解，数据的种类很多，文字、图形、图像、声音、学生的档案记录、货物的运输情况等等，这些都是数据。 我们可以对数据做如下定义：描述事物的符号记录称为数据。描述事物的符号可以是数字，也可以是文字、图形、图像、声音、语言等，数据有多种表现形式，它们都可以经过数字化后存入计算机。 数据库，是存放数据的仓库。只不过这个仓库是在计算机存储设备上，而且数据是按一定的格式存放的。所谓数据库中，是指长期存储在计算机内、有组织的、可共享的数据集合。数据库中的数据按一定的数据模型组织、描述和存储，具有较小的冗余度、较高的数据独立性和易扩展性，并可为各种用户共享。 数据库管理系统是位于用户与操作系统之间的一层数据管理软件，它负责科学地组织和存储数据以及如何高效地获取和维护数据。 7数据库系统的分类 集中型在这种结构中，客户程序连接某台指定的机器并通过其完成交易。数据库放置在同一台机器上，或指定一台专门的机器充当数据库 服务器。 数据分布型数据分布型结构类似前一种结构，只是数据库分布在每台服务器上。它具有的优点是：无单点失败且可独立进行管理。我们可以 将这种结构用于数据分割，例如逻辑分割和地理分割。 数据集中型这种结构是对集中型的一种增强，由其中的一台机器作为数据存取服务器，而在前台提供更多的应用服务器，共享一个数据库服 务器。这种情况下，必须使用数据库软件提供的并行处理功能及硬件 厂商提供的硬件集群策略。 高可用性现在，所有用户都希望在硬件出现错误时，应用的迁移能更加简单，并且在迁移的同时能保证系统继续运行且尽量减少人工干预。 中间件可以提供这样的功能，它可以帮助操作系统自动迁移关键组件 到正常的机器上。 8数据库类型的开发方式与访问接口 数据库类型的开发方式主要是用分布式组件技术。组件是独立于特定的程序设计语言和应用系统、可重用和自包含的软件成分。组件是基于面向对象的，支持拖拽和即插即用的软件开发概念。基于组件技术的开发方法，具
任课教师签名： 日期： 注：1. 以论文或大作业为考核方式的课程必须填此表，综合考试可不填。“简要评语”栏缺填无效。 2. 任课教师填写后与试卷一起送院系研究生秘书处。 3. 学位课总评成绩以百分制计分。
图书管理信息数据库系统-JAVA实 现 目录 一、需求说明 (3) 1、任务概述 (3) 2、需求分析 (3) 2.1功能需求 (3) 2.2、数据描述 (3) 2.2.1静态数据 (3) 2.2.2动态数据 (3) 2.2.3数据库介绍 (3) 3、系统功能概要图 (4) 4、运行环境 (4) 二、数据库的设计 (4) 1、数据库设计的关系模型 (4) 2、创建数据库的语句 (5) 3、给数据库中插记录的相关语句 (6) 4、数据字典 (6) 5、ER图 (8) 三、开发方案介绍 (9) 四、应用系统设计 (10) 附录 (18)
一、需求说明 1、任务概述 满足在线书店管理的需求，实现管理流程。主要功能包括用户注册、用户登录、购物商场、在线购物、订单管理、系统导航、用户退出、权限控制等。 2、需求分析 2.1功能需求 在线书店系统作为一个网络购物网站，它仿照淘宝网等知名购物网站，其总体要求即实现购物网站的基本功能。具体功能要求如下： 1)商品管理。这是管理员的功能。要实现增删改查图书、仓库管理的功能。 2)用户管理。包括用户注册、用户登录和用户退出三个方面，用户还可以更改部分注册 信息。用户登录成功后，在首页面可看到书籍展示。 3)购物车管理。可以修改、删除选购书籍，并保存购物列表。当用户退出时或session 失效时，自动保存用户购物车列表书籍。 4)订单管理。要实现生成订单，删除、修改、查询订单，提交订单。提交后的订单，只 能查看订单信息，不能进行修改，也不能删除。 5)权限控制。主页面和注册页面任何人都可以访问，其他页面，只有已经登录成功的用
一、需求分析 1、问题的提出：这是一个企业销售管理系统，设计者的目标是满足公司运营和日常管理的需要，具有对产品，员工，客户管理的功能。销售员可以对销售的产品进行登记，并将销售情况反馈给数据库。管理员可以查看员工信息以及销售情况，管理员登陆后可以添加删除员工，以及销售员以外的特殊操作。为管理的方便性和信息传递的快速性提供了一个很好的平台。系统开发的总体任务是实现售后服务及销售登记自动化。总之，企业销售管理系统要实现登陆验证、商品销售管理、员工信息管理、客户信息管理几大部分。 2、系统的业务功能分析： 销售管理系统是一个典型的数据库开发应用程序，有基础信息模块，销售管理模块查询统计模块，系统设置模块4部分组成，规划系统功能模块如下： 基础信息模块 该模块主要用于管理添加、删除、修改商品信息、客户信息、用户信息。 销售管理模块 该模块主要用于管理添加销售信息和添加销售退货信息。 查询统计模块 该模块主要用于产品信息查询，销售退货信息查询，和产品销售排行。 系统设置模块 该模块主要用于管理修改密码，关于和退出登录。 3、E-R图： 根据以上各节对系统所做的需求分析和系统分析，规划处了本系统的数据库实体。下面介绍几个关键实体的E-R图：
总体 2-1E-R图 客户编号销售单据编号成交日期产品编号销售单据销售人员数量售价 产品编号入库时间产品名称产品成本库存供应商产地生产日期
用户编号加入时间用户信息用户姓名用户密码用户类型 图2.2 销售信息管理系统详细E-R图 4、数据流图： 销售单据信息购买信息订购处理销售信息客户货品信息销售员退货信息退货要求退货信息退货处理退货信息表 数据流图 三、系统设计 1、数据表：表的物理设计： 建立T_Customer表(客户信息表)，T_Product表(产品信息表)，T_User表(用
第六章信息系统与数据库 一、选择题 .以下列出了计算机信息系统抽象结构层次，其中的数据库管理系统和数据库。.属于业务逻辑层 属于资源管理层 属于应用表现层 不在以上所列层次中 . 以下列出了计算机信息系统抽象结构的个层次，在系统中为实现相关业务功能（包括流程、规则、策略等）而编制的程序代码属于其中的。 基础设施层 业务逻辑层 资源管理层 应用表现层 . 以下列出了计算机信息系统抽象结构的个层次，系统中的硬件、系统软件和网络属于其中的。 .基础设施层 .业务逻辑层 .资源管理层 .应用表现层 . 以下列出了计算机信息系统抽象结构层次，在系统中可实现分类查询的表单和展示查询结果的表格窗口。 属于业务逻辑层 属于资源管理层 属于应用表现层 不在以上所列层次中 . 以下关于语言的说法中，错误的是 的一个基本表就是一个数据库 语言支持三级体系结构 .一个基本表可以跨多个存储文件存放 的一个二维表可以是基本表，也可以是视图 . 信息系统采用模式时，其“查询请求”和“查询结果”的“应答”发生在之间。浏览器和服务器 浏览器和数据库服务器 服务器和数据库服务器 任意两层 . 关系数据库的查询操作由个基本运算组合而成，其中不包括。 连接 选择 投影 比较 . 信息系统采用的模式，实质上是中间增加了的模式。 服务器 浏览器
数据库服务器 文件服务器 . 在信息系统的模式中，是之间的标准接口。 服务器与数据库服务器 浏览器与数据库服务器 浏览器与服务器 客户机与服务器 . 计算机信息系统中的三层模式是指。 应用层、传输层、网络互链层 应用程序层、支持系统层、数据库层 浏览器层、服务器层、服务器层 客户机层、网络层、网页层 . 是，用户可以直接将语句送给。 一组对数据库访问的标准 数据库查询语言标准 数据库应用开发工具标准 数据库安全标准 . 所谓“数据库访问”，就是用户根据使用要求对存储在数据库中的数据进行操作。它要求。 .用户与数据库可以不在同一计算机上而通过网络访问数据库；被查询的数据可以存储在多台计算机的多个不同数据库中 .用户与数据库必须在同一计算机上；被查询的数据存储在计算机的多个不同数据库中 .用户与数据库可以不在同一计算机上而通过网络访问数据库；但被查询的数据必须存储同一台计算机的多个不同数据库中 .用户与数据库必须在同一计算机上；被查询的数据存储在同一台计算机的指定数据库中 是，用户可以直接将语句送给。 .一组对数据库访问的标准 .数据库查询语言标准 . 数据库应用开发工具标准 .数据库安全标准 . 查询语句：，，， ，， ＝＝＝‘男’； 涉及的和三个表。和表之间和和表之间分别通过公共属性 作连接操作。 . 在模式的网络数据库体系结构中，应用程序都放在上。 浏览器 数据库服务器 服务器 客户机 . 语言提供了语句进行数据库查询，其查询结果总是一个。
Introduction to database information management system The database is stored together a collection of the relevant data, the data is structured, non-harmful or unnecessary redundancy, and for a variety of application services, data storage independent of the use of its procedures; insert new data on the database , revised, and the original data can be retrieved by a common and can be controlled manner. When a system in the structure of a number of entirely separate from the database, the system includes a "database collection." Database management system (database management system) is a manipulation and large-scale database management software is being used to set up, use and maintenance of the database, or dbms. Its unified database management and control so as to ensure database security and integrity. Dbms users access data in the database, the database administrator through dbms database maintenance work. It provides a variety of functions, allows multiple applications and users use different methods at the same time or different time to build, modify, and asked whether the database. It allows users to easily manipulate data definition and maintenance of data security and integrity, as well as the multi-user concurrency control and the restoration of the database. Using the database can bring many benefits: such as reducing data redundancy, thus saving the data storage space; to achieve full sharing of data resources, and so on. In addition, the database technology also provides users with a very simple means to enable users to easily use the preparation of the database applications. Especially in recent years introduced micro-computer relational database management system dBASELL, intuitive operation, the use of flexible, convenient programming environment to extensive (generally 16 machine, such as IBM / PC / XT, China Great Wall 0520, and other species can run software), data-processing capacity strong. Database in our country are being more and more widely used, will be a powerful tool of economic management. The database is through the database management system (DBMS-DATA BASE MANAGEMENT SYSTEM) software for data storage, management and use of dBASELL is a database management system software. Information management system is the use of data acquisition and transmission technology, computer network technology, database construction, multimedia
目录 实验一数据库表的创建 (1) 实验二数据库表的查询 (7) 实验三数据库模型设计 (12) 实验四数据库设计 (15)
实验一数据库表的创建 1)启动SQL Server2008, “SQL Server Manange ment Studio” 2)单击链接（C） 打开“SQL Server Manange ment Studio”窗口，并在左边的目录树结构中选择“数据库”文件夹。 3) 单击右键，选择“新建数据库”命令，打开“新建数据库” 对话框，在“数据库名称”框内输入名称“教学管理系统”，注意数据文件和日志文件的属性设置
4) 单击“确定”按钮，完成“教学管理系统”数据库的创建。 5）在左边的目录树中展开“数据库”下刚才创建的“教学管理系统” 文件夹，然后在“表”对象上单击右键，选择“新建表”，右边窗格中显示SQL Server 2008的表设计器。 学生学号char(7) 学生身份证号char(18) 学生姓名char(10) 学生性别char(2) 学生移动电话char(11) 学生来自的城市char(10) 学生主修专业char(20) 学生院系char(20) 学生累计修满的学分int
6）设置主键 在表设计器中选择“学生学号”，右击，选择“设置主键”，得到下图，主键设置成功 7）展开表右击dbo.Student，选择编辑前200行,输入以下数据 再新建查询输入语句 select*from student 得到结果： 8）修改表可以按照 展开表右击dbo.Student，选择编辑前200行,改第一行数据 S060101 ******19880526*** 王东民男135***11 杭州计算机信息学院160 改为： S060101 ******19880526*** 黄星星男135***11 随州电子信息信息学院160
前面将数据及其来源进行了梳理，让我们对B2C网站可能出现的数据有了大概了解。但如何对这些数据进行组织、描述、分类，以便于日常使用呢？ 一、从查询说起 常用查询方式主要有条件查询、模糊查询。 1.条件查询相对比较简单，通过选择一定条件，实现查询/筛选功能。例如下图中的红色框部分。 2.模糊查询又称作关键字/自定义查询，主要通过关键字匹配，实现查询功能。如下图中的蓝色框部分。 图1 查询的常用方式 无论何种查询方式，都是通过程序语句对后台数据库进行查询操作，所以我们需要对数据在入库前进行命名描述、分类汇总，才能通过各种查询方式得到想要的结果，这一步骤就称为标签处理。 二、那什么是标签呢？ 在梳理数据时，我们了解这些数据分别代表的意义，但只了解意义远远不够，更需要站在业务应用角度，去判断、理解数据所代表的意义。 例：如果单纯从用户背景资料(性别、生日等)分析，不同性别用户对产品需求会有差异。但运营需要更进一步分析，希望数据能更多更有用信息，所以在数据准备上，可以将性别、年龄与用户行为进行交叉分析，以便得出更为精确的结果。
图2 基于用户背景资料与用户行为的交叉分析 “性别、年龄”对我们是可见的，即可以通过这两项找到相应的用户。但对数据库而言“性别、年龄”仅仅是文字表现，是通过该文字表现关联到用户，所以它们就像每个人的名字，可以关联到相应的人一样，而这就是标签。 因此，标签只是一种内容组织方式，是一种关联性很强的关键字，能很方便的帮助我们找到合适的内容及内容分类。 三、标签和标签体系 标签解决的是描述(或命名)的问题，但在实际应用中，还需要解决数据之间的关联。所以，我们通常将标签作为一个体系来设计，从而解决数据之间的关联问题。 一般来说，将能关联到具体用户数据的标签，称为叶子标签。对叶子标签进行分类汇总的标签，称为父标签。父标签和叶子标签共同构成标签体系，但两者是相对概念。例如：下表中，地市、型号在标签体系中相对于省份、品牌，是叶子标签。 表1：某网站标签体系示例 一级标签二级标签三级标签四级标签 移动属性用户所在地省份地市手机品牌品牌型号 业务属性用户等级普通 音乐普通会员音乐高级会员音乐VIP会员 四、用户标签体系与商品标签体系
VOC在线监测管理系统 背景介绍 1、项目背景 随着经济的快速发展，污染源的种类日益增多，特别是化工区、工业集中区及周边环境，污染方式与生态破坏类型日趋复杂，环境污染负荷逐渐增加，环境污染事故时有发生。同时，随着公众环境意识逐渐增强，各类环境污染投诉纠纷日益频繁，因此对环境监测的种类、要求越来越高。 在“十二五”期间，政府着力打造以空气环境监测，水质监测，污染源监测为主体的国家环境监测网络，形成了我国环境监测的基本框架。“十三五”规划建议中已经明确“以提高环境质量为核心”，从目前环保部力推的“气，水，土三大战役”的初步效果来看，下一步对于环境质量的改善则是对于现有治理设施和治理手段的检验。而对于三个领域治理效果的检验，依赖于全面有效的环境监测网络。 国务院印发的《生态环境监测网络建设方案的通知》提出建设主要目标：到2020年，全国生态环境监测网络基本实现环境质量、重点污染源、生态状况监测全覆盖，各级各类监测数据系统互联共享，监测预报预警、信息化能力和保障水平明显提升，监测与监管协同联动，初步建成陆海统筹、天地一体、上下协同、信息共享的生态环境监测网络。 根据调研大部分企业具备简单治理技术，即将生产车间内生产工艺所产生的VOCs污染物通过管道集气罩收集后通过活性炭吸附装置处理以后进行排放，但园区内存在着有组织排放超标和无组织排放的问题，为督促企业改进生产工艺和治理装置，减少无组织排放，建议园区部署网格化区域监控系统。 系统部署可提高各工业工园区污染源准确定位能力，同时快速直观的分析出污染源周边的相关信息，通过整合各类地理信息资源和环境保护业务资源，建立统一的环境信息资源数据库，将空间数据与动态监测数据、动态监管数据、政策法规数据等业务数据进行无缝衔接。为管理者提供直观、高效、便捷的管理手段，提高环保业务管理能力，综合管理与分析的决策能力。同时根据业务应用的不同，对数据进行横向的层次划分，通过应用人员层次的不同，对数据进行纵向的层次划分，明晰信息的脉络，方便数据的管理。 2、建设依据 2.1相关政策、规划和工作意见 《国务院关于印发国家环境保护“十二五”规划的通知》（国发〔2011〕42号）
数据库系统安全性分析与实现 （刘中胜信息系统项目管理师，高级项目经理） 摘要：随着信息技术的不断发展，各行企业都不同程度地实现了信息化，因而信息系统的应用非常普及，作为信息系统的重要组成部分---数据库系统也就成为重中之重。数据库系统在运行过程中，会受到软件、硬件、人为和自然灾害等各种因素的影响，这些因素不但会破坏数据的机密性、完整性、可用性，造成数据损坏或丢失，而且会影响数据库系统的正常运行，甚至导致数据库系统的崩溃，因此，数据库系统的安全性问题变得尤为突出，不断面临巨大的、新的挑战。本文将从数据库系统的安全属性及安全技术进行分析，探讨实现数据库系统的高安全性策略。 关键字：数据库系统；数据库技术；安全性；安全策略 随着信息技术的不断发展，各行企业都不同程度地实现了信息化，因而信息系统的应用非常普及，作为信息系统的重要组成部分---数据库系统也就成为重中之重。数据库系统在运行过程中，会受到软件缺陷和故障、硬件损坏和故障，人为非法访问和误操作，以及自然灾害等各种因素的影响，这些因素不但影响数据的安全，而且会影响数据库系统的正常运行，甚至导致数据库系统的崩溃，因此，数据库系统的安全性问题变得尤为突出，不断面临巨大的、新的挑战。如何保证数据的安全，如何保证数据库系统正常安全地运行，是我们在实现企业信息化建设过程中必须认真考虑的问题。下面将从数据库系统的安全属性出发，分析构建数据库系统的安全技术，并阐述实现数据库系统高安全性的策略。 一、数据库系统的安全属性分析 对数据库系统安全属性的分析，是实现数据库安全策略的一个重要环节，是一个数据库系统采用恰当安全策略的前提。数据库系统的安全属性涉及多个方面，从总体上来讲，包括机密性、完整性、可用性、可控性和可审查性等属性。 （1）机密性：防止数据被非法窃取、调用或存取而泄密。数据只能被其相应的合法用户访问或调用。 （2）完整性：防止非法用户对数据进行添加、修改和删除，同时也防止合法用户越权访问对未被授权的数据进行添加、修改和删除，并且能够判断数据是否被修改。
仓库管理系统数据库设计 1概述（设计题目与可行性分析） 1.1设计题目 设计一个仓库数据库管理系统，要求实现入库、出库、库存和采购等功能。 随着经济的飞速发展，，仓库管理变成了各大公司日益重要的内容。仓库管理过程的准确性和高效性至关重要。影响着公司的经济发展和管理。利用人工管理强大而数据烦琐的数据库显的效率过于低。利用计算机高效、准确的特点能够很好的满足公司的管理需要。提高公司各个员工的工作效率和公司的运做效率。利用计算机对仓库数据信息进行管理具有着手工管理所无法比拟的优点。目前一个现代化的仓库管理系统已经成为仓库管理不可缺少的管理手段。 1.2 可行性研究 可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决。可行性研究的目的不是解决问题而是分析问题能不能解决；至少从下面三个方面分析可行性研究。 1.2.1技术可行性 该仓库数据库管理系统不不是很复杂，设计实现该数据库技术难度不是很大，利用目前现有的技术和工具能在规定的时间内做出该系统。该系统利用SQL2000和 visual studio 工具就能很好的实现该系统。 1.2.2经济可行性 当今世界是经济时代，一个公司的员工工作效率的高低直接影响着这个公司的发展。因此利用计算机进行信息管理有着无可比拟的好处，该系统相对较小，代码行较少，数据库设计不是很麻烦，开发周期较短。而且便于维护。但其带来的经济效益远远高于其开发成本。在经济上是可行的。 1.2.3操作可行性 在当今社会，随着义务教育的普及。和计算机的普及，公司的员工基本上都会进行电脑的基本操作，由于本软件系统采用相对友好的界面，用户 在使用过程中不需要懂太多的电脑专业知识，只需要基本的电脑操作就可
医院信息系统数据库安全性分析及措施医院信息系统数据库安全性分析及措施 余大勇① ①四二一医院信息科，510000，广东省广州市新港中路468号 摘 要要 数据库系统已经渗透到医疗行业的各个方面，数据库系统的安全问题也时时在威胁医院业务正常的运行与发展。数据安全问题主要有几方面：硬件、系统软件出错，人为错误，计算机病毒，自然灾害等。通过对现数据库系统安全进行分析，统计了本医院数据库意外停机的原因。针对这些原因，提出了数据库安全措施，包括双机策略、磁盘备份策略、数据库容灾策略、数据库备份策略。这些措施对提高医院信息系统数据库安全提供比较可靠的保障。 关键词关键词 医院信息系统 数据库安全 双机备份； 1 1 引言 引言 随着计算机技术的发展，医院信息已成为医疗系统日常活动中十分重要的一个组成部分，医院信息系统的可靠性、安全性、数据的完整性越来越引起广泛的重视。与此同时，数据库系统的安全问题也正在威胁医院信息系统的正常运行。目前，数据安全问题主要有几方面：硬件、系统软件出错，人为错误，计算机病毒，自然灾害等。数据库的数据安全受到严峻的挑战。数据库安全问题已是影响业务安全、健康、高速发展的一大隐患。 2 2 数据丢失的原因数据丢失的原因 根据医院HIS数据丢失的情况，总结数据丢失原因主要是因为数据库系统停机造成的。一般来说，信息管理系统要求24小时不停机，可靠性要求高，不仅不允许出现系统故障后丢失数据，而且要求故障在几分钟甚至几秒之内迅速恢复[1]。 而数据库系统停机可以分为：计划内停机和意外（非计划内）停机。 意外停机主要包括：系统错误：电源突然断电或者服务器磁盘突然损坏或者操作系统突然崩溃 [2]；数据逻辑错误及自然灾害：发生在数据的逻辑错误；自然灾害，如火灾、地震、台风、暴雨等；人为错误：人为误删除某一张表或人为不小心删除某些数据等；系统管理员在日常维护中误删除了某个数据文件。 计划内停机包括：系统维护：增加硬件或系统升级；数据维护：表都重新定义或索引重建或更改表结构等。 对医院信息系统意外停机进行了150次的统计，统计结果见表1。 表1 意外停机统计表 意外停机原因 次数 所占百分比
数据库系统安全、技术操作规程 一．数据库系统概述 在OVATION系统中，RDBMS核心是Ovation Power Tool数据库，由多种分布式数据库支持的主（master）数据库组成。 Ovation系统中许多信息，包括系统配置、控制算法信息和过程点数据库存储在Ovation 数据库中。Ovation数据库提供了结合和产生系统中大量的原始数据的能力，并可以用来创建其他的信息。所有设计工具和用户接口把数据存储在Ovation数据库中，然后把信息传送到控制系统中。Ovation数据库允许应用软件和控制系统通过第三方SQL（结构化查询语言）工具方便的访问数据。 主数据库中信息分成两个主要部分：用户级和系统级。 用户级由下列一组表组成（可以进行所有SQL的读访问）： 点表－表示点的用户级别特性。它们通过导入程序、点建立器和控制建立器来增加。 控制表－表示系统的控制信息，由控制建立器操作。 配置表－表示系统的配置。通过导入程序、Admin Tool和I/O建立器来增加。 参数表－表示Ovation系统内容、硬件模件参数信息，Ovation记录类型信息，并在数据库创建时增加。 基线表－用于捕捉用户级别表内容的基线。 Ovation数据库以Oracle7为基础， Ovation通过网络进行连接，Oracle把存放在不同计算机上的数据结合起来存放在一个逻辑数据库中，并由非控制器网络节点进行访问。
二．数据库信息的存取 2-1. 数据库初始化定义工具（DBID） Power Tool数据库可以通过Power Tool单元支持建立数据库，同时也可以执行大量数据输入和导入功能，将数据存放到Power Tool主数据库中。 为方便初始化Power Tool数据库总体，创建数据库初始化定义工具（DBID）。如Ovation 点建立器，DBID提供了一个图形化用户接口，用于创建、删除和修改点数据。DBID通过允许用户直接修改点表中数据，支持大批量数据输入和全局性编辑/替换功能。 DBID建立在Microsoft Access95数据库产品及其它数据检测程序基础上。DBID同Ovation点建立器程序非常相似，同样包含了定义的窗体及系统中硬件配置及输入和编辑点数据。 数据可以手工输入或者从许多其它源文件，如DBASE或电子数据表格文件中导入，但是根据外部数据结构可能要求一些自定义转换。一旦信息输入到DBID并导入到主数据库中，在点对点基础上通过点建立器进行修改。大批量数据修改可通过将数据从主数据库中导出来完成，然后再把这些数据存回到DBID数据库中。一旦修改完成，文件可重新导入到主数据库中。 DBID生成一个可以导入到Ovation数据库中的文本文件。 2-2. 数据的导入功能（ptdbimp） 导入文件由DBID工具生成后，可使用Power Tool的导入功能（ptdbimp）把数据存入到主数据库中，这与Power Tool导出功能（ptdbexp）配合使用。 导入过程的三个用途： 初始化创建的数据库 修改一个已存在的数据库 恢复数据库为一个可知状态 注意ptdbimp用于生成一个主数据库的导出文件（使用ptdbexp），并且把数据存回到DBID工具中这是重要的。若有必要，可进行大批量更改或添加。一旦完成，DBID可以生成一个导入到主数据库的文本文件。 Ptdmimp程序存放在$WDPF_HOME/db/bin目录下，为使用ptdbimp，在shelltool窗口中运行下列命令： $WDPF_HOME/db/bin> ptdbimp ptadmin
数据库技术 实 验 报 告 学校 专业 年级 学号 姓名 年月日
学生信息管理系统数据库设计 一、数据库的建立 1. 建库说明 数据库的建立用企业管理器，基本表的建立用SQL语言。 数据库名称为：学生信息管理系统。 2. 建立数据库命令如下： Create database 学生信息管理系统 二、数据表的建立 1. 建表 命令： CREATE TABLE [dbo].[学生档案信息] ( [Sno] [varchar] (50) NOT NULL , [Sname] [char] (10) NOT NULL , [Ssex] [char] (10) NOT NULL , [Sclass] [char] (10) NOT NULL , [Birth] [int] (4) NOT NULL , [Saddress] [char] (10) NOT NULL , [Sdept] [varchar] (50) NOT NULL , [Stime] [int] (4) NOT NULL ,
) ON [PRIMARY] GO （2）班级设置信息表： 命令： CREATE TABLE [dbo].[班级设置信息] ( [Sgrade] [char] (10) NOT NULL , [Szclass] [int] (4) NOT NULL , [Syear] [char] (5) NOT NULL , [Scroom] [char] (5) NOT NULL , [Steacher] [char] (10) NOT NULL , [Stotal] [int] (4) NOT NULL , [Ssub] [varchar] (8000) NOT NULL , ) ON [PRIMARY] GO （3）院系信息表： 命令： CREATE TABLE [dbo].[院系信息] ( [Syname] [varchar] (50) NOT NULL , [Spro] [varchar] (1000) NOT NULL ,
操作系统以及数据库运行安全管理办法 1范围 为保障XX公司信息通信分公司（以下简称“公司”）管理信息系统的操作系统和数据库管理系统的安全、稳定运行，规范操作系统和数据库管理系统的安全配置和日常操作管理，特制订本管理办法。 本办法适采用于公司信息系统的操作系统和数据库系统的管理和运行。 2规范性引采用文件 下列文件中的条款通过本标准的引采用而成为本标准的条款。凡是注日期的引采用文件，其随后全部的修改单（不包括勘误的内容）或修订版均不适采用于本标准，使采用本标准的相关部门、单位以及人员要研究是否可使采用这些文件的最新版本。凡是不注日期的引采用文件，其最新版本适采用于本标准。 ——中华人民共和国计算机信息系统安全保护条例 ——中华人民共和国国家安全法 ——中华人民共和国保守国家秘密法 ——计算机信息系统国际联网保密管理规定 ——中华人民共和国计算机信息网络国际联网管理暂行规定 ——ISO27001标准/ISO27002指南 ——公通字[2007]43号信息安全等级保护管理办法 ——GB/T 21028-2007 信息安全技术服务器安全技术要求 ——GB/T 20273-2006 信息安全技术数据库管理系统安全技术要求 ——GB/T 20272-2006 信息安全技术操作系统安全技术要求 ——GB/T 20269-2006 信息安全技术信息系统安全管理要求 ——GB/T 22239-2008 信息安全技术信息系统安全等级保护基本要求 ——GB/T 22240-2008 信息安全技术信息系统安全等级保护定级指南
3术语和定义 下列术语和定义适采用于本标准 操作系统安全:操作系统所存储、传输和处理的信息的保密性、完整性、和可采用性表征。 数据库管理系统安全:数据库管理系统所存储、传输和处理的信息的保密性、完整性和可采用性的表征。 4操作系统运行管理 4.1操作系统管理员的任命 4.1.1操作系统管理员的任命应遵循“任期有限、权限分散”的原则； 4.1.2对每个操作系统要分别设立操作系统管理员和操作系统审计员，并分别由不同的人员担任。在多套系统的环境下，操作系统管理员和操作系统审计员岗位可交叉担任； 4.1.3操作系统管理员和操作系统审计员的任期可据系统的安全性要求而定，最长为三年，期届满通过考核后可续任； 4.1.4操作系统管理员和操作系统审计员须签订保密协议书。 4.2操作系统管理员帐户的授权、审批 4.2.1操作系统管理员和操作系统审计员账户的授权由所在部门填写《操作系统账户授权审批表》，经部门领导批准后设置； 4.2.2操作系统管理员和操作系统审计员人员变更后，须尽快更改帐户设置。 4.3其他帐户的授权、审批 4.3.1其他账户的授权由使采用人填写《操作系统账户授权审批表》，经信息管理部门领导批准后，由操作系统管理员进行设置； 4.3.2外单位人员需使采用公司系统时, 须经信息管理部门领导同意, 填写《外单位人员操作系统账户授权审批表》，报信息管理部门领导批准后, 由操作系统管理员按照规定的权限、时限设置专门的采用户帐号； 4.3.3禁止公司任何人将自己的采用户帐号提供给外单位人员使采用。
中英文对照翻译 信息系统开发和数据库开发 在许多组织中，数据库开发是从企业数据建模开始的，企业数据建模确定了组织数据库的范围和一般内容。这一步骤通常发生在一个组织进行信息系统规划的过程中，它的目的是为组织数据创建一个整体的描述或解释，而不是设计一个特定的数据库。一个特定的数据库为一个或多个信息系统提供数据，而企业数据模型（可能包含许多数据库）描述了由组织维护的数据的范围。在企业数据建模时，你审查当前的系统，分析需要支持的业务领域的本质，描述需要进一步抽象的数据，并且规划一个或多个数据库开发项目。图1显示松谷家具公司的企业数据模型的一个部分。 1.1 信息系统体系结构 如图1所示，高级的数据模型仅仅是总体信息系统体系结构(ISA)一个部分或一个组织信息系统的蓝图。在信息系统规划期间，你可以建立一个企业数据模型作为整个信息系统体系结构的一部分。根据Zachman(1987)、Sowa和Zachman （1992）的观点，一个信息系统体系结构由以下6个关键部分组成: 数据（如图1所示，但是也有其他的表示方法）。 操纵数据的处理（着系可以用数据流图、带方法的对象模型或者其他符号表示）。 网络，它在组织内并在组织与它的主要业务伙伴之间传输数据（它可以通过网络连接和拓扑图来显示）。 人，人执行处理并且是数据和信息的来源和接收者（人在过程模型中显示为数据的发送者和接收者）。 执行过程的事件和时间点（它们可以用状态转换图和其他的方式来显示）。 事件的原因和数据处理的规则（经常以文本形式显示，但是也存在一些用于规划的图表工具，如决策表）。 1.2 信息工程 信息系统的规划者按照信息系统规划的特定方法开发出信息系统的体系结构。信息工程是一种正式的和流行的方法。信息工程是一种面向数据的创建和维护信息系统的方法。因为信息工程是面向数据的，所以当你开始理解数据库是怎样被标识和定义时，信息工程的一种简洁的解释是非常有帮助的。信息工程遵循自顶向下规划的方法，其中，特定的信息系统从对信息需求的广泛理解中推导出来（例如，我们需要关于顾客、产品、供应商、销售员和加工中心的数据），而不是合并许多详尽的信息请求（如一个订单输入屏幕或按照地域报告的销售汇总）。自顶向下规划可使开发人员更全面地规划信息系统，提供一种考虑系统组件集成的方法，增进对信息系统与业务目标的关系的理解，加深对信息系统在整个组织中的影响的理解。 信息工程包括四个步骤:规划、分析、设计和实现。信息工程的规划阶段产